Barry Leiba has entered the following ballot position for draft-ietf-ipsecme-ikev2-null-auth-06: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First: Thanks, Paul, for a very informative and useful shepherd writeup. I have no problem with the reference to Experimental RFC 5739, but I do have a problem with the downref not having been noted in the last call announcement, as required by RFC 3967 (BCP 97). And I think the MUST in the last paragraph of Section 2.5 requires 5739 to be normative. I hate to say this, but I think this requires a second last call on this document, which will really serve no one. We really do need to do an update to BCP 97 to fix this, because it comes up all the time. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial comment in Section 2: If a peer that requires authentication receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. We're referring to NULL authentication as "authentication", so maybe this should say something like "If a peer that requires positive identification receives [...]", or "If a peer that requires authenticated identity receives [...]" ? _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
