Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
Note: This ballot was opened for revision 07 and is now closed.
(Richard Barnes) Yes
Comment (2014-05-15 for -07)
To Stephen's point and Pete's: I suggested "REALLY SHOULD NOT" [RFC6919]
(Ted Lemon) Yes
(Kathleen Moriarty) Yes
(Jari Arkko) No Objection
(Benoît Claise) No Objection
Alissa Cooper No Objection
(Spencer Dawkins) No Objection
(Adrian Farrel) No Objection
Comment (2014-05-13 for -07)
Barry caught one of my concerns... I agree that "SHOULD-implement" is open to confusion. --- Please consider renaming 2.5. Summary of Changes to 2.5. Summary of Changes from RFC 4835 Also please consider adding an introductory line of text in that section to clarify what it is talking about. --- It would appear that the editor note in Section 6 is no longer needed. At least, I removed it and idnits was quite happy.
(Stephen Farrell) (was Discuss) No Objection
(Brian Haberman) No Objection
(Joel Jaeggli) No Objection
Barry Leiba (was Discuss) No Objection
Comment (2014-05-09 for -07)
-- Section 3 -- Both confidentiality and authentication SHOULD be provided. If confidentiality is not needed, then authentication MAY be provided. Confidentiality without authentication is not effective [DP07] and SHOULD NOT be used. We describe each of these cases in more detail below. This says that if you confidentiality is not needed, authentication is *entirely* optional, and there is *no* recommendation being made about the use of authentication alone. Discussion with Paul indicates that that isn't what's meant, but that (1) the WG wasn't able to agree on better text, and (2) tweaking that sentence isn't going to affect implementations anyway. I think the failure here is in trying to stuff 2119 language in. Because the next paragraph goes into more details and uses the 2119 key words (and I think it gets it right), a good option might be to lose the 2119 key words in this short paragraph, and just have this be a lead-in to the next one. This one explains what you're getting at, and the next one puts in the details with the 2119 language. Some totally editorial stuff... no response needed either way: -- Section 4 -- Because you use "SHOULD-", it strikes me that "SHOULD-implement" might be misunderstood to refer only to "SHOULD-" algorithms. I suggest changing it this way: OLD The algorithms listed as MAY-implement are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being SHOULD-implement to MAY-implement algorithms. NEW The algorithms listed as "MAY implement" are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being "SHOULD implement" to "MAY implement" algorithms. END -- Section 6 -- I wouldn't normally pick on anything in the "Acks" section, but there's this: Much of the wording herein was adapted from [RFC4835], the parent document of this document. Actually, only the Security Considerations and one paragraph from the Introduction survive from 4835, and I'd hardly call the rest "adapted". If you want to leave it as it is, that's fine and this is the last you'll hear from me about it. But it might make sense to reword that to acknowledge the role of 4835 relative to this document somewhat more accurately.
(Pete Resnick) No Objection
Comment (2014-05-14 for -07)
I am glad Barry and Adrian have already commented. I roll my eyes, wonder why this document did not reference RFC 6919, and move on with my day.