Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4305
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Allison Mankin; former steering group member) Yes
(Jon Peterson; former steering group member) Yes
(Russ Housley; former steering group member) Yes
(Steven Bellovin; former steering group member) Yes
3.1.1 is actually rather odd -- there are no mandated confidentiality algorithms defined that are both required today and expected to be required in the near future.
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
Reviewed by Brian Carpenter, Gen-ART Personally, I think the use of SHOULD+ and MUST- are good additions to the repertoire of "conformance verbs". My preference would be to have the document mention an expected date for the conformance change (like "the first version emitted after January 2006, unless we learn something new"), but I can easily live with the document as written.
(Margaret Cullen; former steering group member) No Objection
Ideally the mandatory to implement algorithm of tomorrow should already be available in most implementations of IPSEC by the time it is made mandatory. s/IPSEC/IPsec If the security folks can't get this right, how can we expect the rest of us to do so? :-)
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) (was Discuss) No Objection
s/IPSEC/IPsec/ throughout. s/mandatory to implement algorithms/mandatory-to-implement algorithms/ > a MAY or worse in a future version of this document. s/or worse/or weaker/ ?? 4 normative references to IDs; are those IDs done?