Hi Roman, > Roman Danyliw has entered the following ballot position for > draft-ietf-ipsecme-g-ikev2-20: Discuss > > 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.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 9.2. This section defines a number of registries that have an > allocation policy of “Expert Review”. However, this document does not provide > guidance to the designated expert on what to approve. See Section 4.5 of > RFC8126.
I've added Section 9.2.1: 9.2.1. Guidance for Designated Experts In all cases of Expert Review Policy described here, the Designated Expert (DE) is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested code points. Last, the DE must verify that any specification produced outside the IETF does not conflict with work that is active or already published within the IETF. (most of the text is shamelessly borrowed from RFC 7752, which RFC 8126 lists as a good example of guidance for experts). > ** Section 9.3. Shouldn’t the code points referenced in this section which > currently reference “[draft-yeung-g-ikev2-07]” be updated to reference this > document (e.g., 39 – 41 of “IKEv2 Exchange Types”, 50 – 52 of "IKEv2 Payload > Types", 45-46 of "IKEv2 Notify Message Error Types", 16429 of “IKEv2 Notify > Message Status Types”)? Hmm, I've been always thinking that this will be done automatically by IANA, since draft-yeung-g-ikev2 is a predecessor of this draft, thus these are just a (very) early code point allocations... Note, that according to the IANA review of draft-17 (IANA #1399843), the IANA understands that it should update all these references to the [RFC-to-be]. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Robert Sparks for the GENART review. > > ** Section 9.2. Should all the new registries created by this section have an > addition column added to them to be “Reference” that points to the > specification further explaining the code point? Yes, and the IANA usually adds this column automatically (at least for IPsec documents we never requested this explicitly before). IANA review of draft-17 (IANA #1399843) indicates that this case will not be an exception. > ** Section 9.2. The registries “Group-wide Policy”, "Group Key Bag > Attributes" > and "GSA Attributes" have a “Format”, “Multi-Valued” and/or “Protocol” but the > meaning of those columns is not explicitly stated. Good point. I don't think the meaning of these columns should be explained in the IANA Considerations Section. Instead, I think it it appropriate to do this in the text, where these registries are introduced. 1. The "Protocol" column is changed to "Used in Protocol" 2. The following text is added at the bottom of 4.4.2.2 and 4.5.2: The attributes follow the format defined in the IKEv2 [RFC7296] section 3.3.5. The "Format" column defines what attribute format is allowed: Type/Length/Value (TLV) or Type/Value (TV). The "Multi- Valued" column defines whether multiple instances of the attribute can appear. The "Used in Protocol" column lists the security protocols, for which the attribute can be used. 3. The following text is added at the bottom of 4.4.3.1 and 4.5.3: The attributes follow the format defined in the IKEv2 [RFC7296] section 3.3.5. The "Format" column defines what attribute format is allowed: Type/Length/Value (TLV) or Type/Value (TV). The "Multi- Valued" column defines whether multiple instances of the attribute can appear. You can review the changes here: https://github.com/smyslov/G-IKEv2/pull/28 Let us know if more changes are needed. Regards, Valery. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
