Hi Roman, the just posted -21 version addresses your DISCUSS.
Regards, Valery. > -----Original Message----- > From: Valery Smyslov <[email protected]> > Sent: Tuesday, February 4, 2025 3:26 PM > To: 'Roman Danyliw' <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected] > Subject: RE: Roman Danyliw's Discuss on draft-ietf-ipsecme-g-ikev2-20: (with > DISCUSS and COMMENT) > > 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 -- [email protected] To unsubscribe send an email to [email protected]
