Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-esp-ah-reqts-10

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.

-- 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.

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.