Subject: [babel] Kathleen Moriarty's No Objection on charter-ietf-babel-00-02: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 01 Jun 2016 13:39:15 -0700

Kathleen Moriarty has entered the following ballot position for
charter-ietf-babel-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-babel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is really just a question and may result in updated text or not...

I think by the following, you mean there will be a draft specific to
security:

Thus, the working group will produce a Proposed Standard Babel
specification, including or paired with a suitable security
specification for BABEL.

Or do you mean that you will cover security requirements and
considerations in each of the other drafts produced?

Thanks.

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 02 Jun 2016 10:48:10 +0100

Hello.

The sense it makes to me is as follows:
1. The PS must include a security mechanism.
2. The specification of the mechanism may be a standalone document or an appendix in the main document.
3. Particular form is up to WG and depends on the nature of the text that becomes a part of the PS.
4. This may have to do with RFC 7298 or some other specification.

To me it seems that a good security mechanism spec would always include two parts. One would just say "To implement this spec do this and this". The other would discuss why it needs to be done and what are the options and possible side-effects and what if... Some authors find it better to include the "do this" part as an appendix of the main document and to make the "let's discuss this" part a standalone security considerations document. Others find it better to put both parts into one standalone document. RFC 6126 and RFC 7298 were produced by different authors at different time, so RFC 7298 naturally combined both those parts.

The matter here is, the security considerations are always a part of the work to be done, whichever document they happen to belong. The WG may agree to:
* base the work on RFC 7298 and leave it one document (makes perfect sense to me but I am biased), or
* idem but put some contents into RFC 6126-bis appendix and the remaining into a new separate "considerations/applicability" document, or
* proceed with a different mechanism but still have to have a normative text and a considerations text.

The current revision of the charter seems to allow the flexibility for doing that.

-- 
    Denis Ovsienko

---

From: [email-masked]
Date: Thu, 2 Jun 2016 09:38:44 -0400

Sent from my iPhone

> The current revision of the charter seems to allow the flexibility for doing that.

Ok, thanks for the clarification.  It doesn't read as clearly to me, but is fine if the proponents and AD don't want to adjust the text.  You are covering security and that's what I really care about.

Thanks,
Kathleen