[Gen-art] Re: Gen-art review of draft-manral-ipsec-rfc4305-bis-errata-02.txt

Hi Elwyn,

Thanks a lot for the very detailed comments. They are all very useful.

I will reword section 4 to make it clearer - including changing the
sectionn heading. I have got similar comments from Nico and Russ on
the section too. I will also remove Appendix A and Merge Appendix B. I
will also take care of all the reference changes as well as other
nit's you have pointed to.

Thanks again,
Vishwas

On 12/12/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>
> Document: draft-manral-ipsec-rfc4305-bis-errata-02.txt
> Reviewer: Elwyn Davies
> Review Date: 12 December 2006
> IETF LC End Date: 4 January 2007
> IESG Telechat date: (if known) -
>
> Summary:
> My comments are significantly longer than the actual changes made to
> this document since RFC 4305. Doh!
>
> The document states that it updates RFC4305 but I believe that it it
> obsoletes it - the substantive content either duplicates or replaces
> RFC4305, and there is additional material. It would be better to provide
> a separate section detailing the changes relative to RFC4305 rather than
> conflating them with the changes between RFCs 2402/2406 and RFC 4305
> (and it partially duplicates Appendix B).
>
> I will leave the discussion of the rights and wrongs of downgrading the
> NULL algorithm for AH to a 'MAY' to the security experts.
>
> The whole new section entitled 'Application Support' seems problematic.
>
> The document also needs some editorial cleanup before going to the IESG.
> Also there is an item called out in Appendix A which may indicate that
> there is something missing but I suspect that this represents a problem
> with the appendix rather than a real missing item.
>
> Issues:
>
> Section 4:
>
> Reading this section naively I was thinking this is about what an
> application can use - the first paragraph seems to support this view but
> the second paragraph goes off into the weeds and seems to be talking
> about what happens in real implementations of the IPsec layer. I think
> this is poor wording and maybe a misleading title. Would 'Application
> Expectations' be more appropriate?
>
> The second paragraph certainly needs more work. It states:
> Any application using ESP or AH should use the algorithm supported in
> this document. However an application can mandate the support of a more
> stringent set of algorithm support as well as add support for new
> algorithms, however the application cannot make the requirements
> more lenient(i.e. MUST cannot be made a MAY or a SHOULD though a SHOULD
> and a MAY can be made to a MUST).
>
> Comments:
> Sentence 1: 'the algorithm'? There is more than one. Is this trying to
> say 'An application will be most likely to have its requirements from
> the IPsec layer if it requests one of the MUST algorithms'? Well it
> should be motherhood and apple pie.
> Sentence 2, clause 1: Reword to make it clear that the mandate is about
> what the application will accept rather than mandating changes to the
> IPsec layer. The phrase 'a more stringent set of algorithm support' is
> unclear - is this just saying the application can be written to accept
> only a subset of the potentially supported algorithms? An application
> cannot 'add support' for new algorithms (one reading would be that this
> was adding new algorithms to those implemented in the IPsec layer). It
> could 'require support' or 'prefer support' of new (presumably
> cryptographically stronger) algorithms.
> Sentence 2, clause 2: I am at a loss to see how an application can
> affect the algorithm requirements in any way. Are we just saying that an
> application cannot expect to have its requirements met in all cases if
> it exclusively mandates the use of 'MAY' algorithms?
>
> Assuming we need to say it at all, I *think* (but am not exactly sure)
> that the second para could be redrafted as:
> An application SHOULD (MUST?) expect to be able to express preferences
> about the ESP and AH algorithms to be used for its messages. An
> application SHOULD be able to constrain the choices of algorithms used
> for its
> messages and MAY request the use of alternative (generally
> cryptographically stronger) algorithm(s) that
> might be supported by an implementation of IPsec. An application that
> does not include any of the mandatory
> to implement algorithms in its set of allowed algorithms cannot expect
> to communicate successfully on all
> IPsec implementations.
>
> Is Appendix A correct? It states:
>
> Appendix A. To be done
>
> o Support for any new algorithms and updating state for existing algorithms.
>
> I think that this has been done, so either remove it or action it if I
> am wrong!
>
> A number of editorial fixes are needed
>
> - Sort out the section numbering in the table of contents (two Section
> 4's currently!)
> - Sort out the references as noted in the warnings from idnits (copied
> below). Also, the document (US Government Federal Register (Docket No.
> 040602169-4169-01)) referred to in Section 7 probably ought to be a
> reference. (although this is a hangover from RFC4305 so I won't press
> this one).
> - Sort out the formatting and remove non-ASCII characters as per idnits
> plus checking the page end flag characters from the end of page 5
> onwards (they aren't formfeeds).
> - Add (null) IANA requirements section
> - Reduce the length of the abbreviated title (it doesn't fit on the
> header line)
> - Add RFC Editor note instructing removal of appendices before publication.
> - Integrating the changes made in this document and RFC 4305 is
> confusing - and duplicates Appendix B.
> * Change the title of Section 7 - 'Changes from RFC 2402 and 2406 to RFC
> 4305' and
> return it to the text of RFC4305.
> * Replace Appendix B with a main body section recording the changes from
> RFC4305.
> - The comment in Section 7 (duplicated from RFC4305) is factually
> incorrect in this document: 'But this document represents the first
> standards-track recognition of that deprecation'. Replace 'this document
> represents' by 'RFC 4305 represented'.
> - Section 5 title should now be 'Acknowledgments' (plural)
>
>
> idnits 1.121
>
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt:
>
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(10): Found control character TAB in position 1.
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(80): Line is too long: the offending characters are '0'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(81): Line is too long: the offending characters are '0'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(271): Line is too long: the offending characters are 're'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(274): Line is too long: the offending characters are 'LD'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(309): Line is too long: the offending characters are 'ent'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(310): Line is too long: the offending characters are 'raphic'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(317): Found non-ascii character (�) in position 54.
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(493): Line is too long: the offending characters are ','
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(493): Found non-ascii character (�) in position 50.
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(536): Line is too long: the offending characters are 'lgorithms.'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(546): Line is too long: the offending characters are 'sion'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(551): Line is too long: the offending characters are 'NULL'
> tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(554): Line is too long: the offending characters are 'or SHA-1'
>
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>   * The document seems to lack an IANA Considerations section.
>
>     Checking conformance with RFC 3978/3979 boilerplate...
>
>   - This document has ISOC Copyright according to RFC 3978, instead of the
>     newer IETF Trust Copyright according to RFC 4748.  You should consider
>     updating it; the new Copyright statement will be required from February
>     1st, 2007
>   - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of
>     the newer disclaimer which includes the IETF Trust according to RFC 4748.
>     You should consider updating it; the new disclaimer will be required from
>     February 1st, 2007
>
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>   - The page length should not exceed 58 lines per page, but there was 3
>     longer pages, the longest (page 1) being 60 lines
>
>   Miscellaneous warnings:
>   - The document seems to lack the recommended RFC 2119 boilerplate, even if
>     it appears to use RFC 2119 keywords.
>
>     RFC 2119 paragraph 2 text:
>     "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are to be interpreted as described in RFC 2119."
>
>     (The document does seem to have the reference to RFC 2119 which the
>     ID-Checklist requires).
>
>   Experimental warnings:
>
> [Added by Elwyn Davies: The warnings about IKEv2 and RFC2409 are spurious.]
>
>   - Missing Reference: 'RFC2451' is mentioned on line 161, but not defined
>     'MUST-          TripleDES-CBC [RFC2451]...'
>
>   - Unused Reference: 'IPsec' is defined on line 322, but not referenced
>     '[IPsec]     Kent, S., "Security Architecture for the Internet Proto...'
>
>   - Unused Reference: 'JIS' is defined on line 356, but not referenced
>     '[JIS]       Schiller, J., "Cryptographic Algorithms for Use in the...'
>
>   - Unused Reference: 'IKEv2' is defined on line 366, but not referenced
>     '[IKEv2]     Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protoc...'
>
>   - Unused Reference: 'RFC791' is defined on line 369, but not referenced
>     '[RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791, Septem...'
>
>   - Unused Reference: 'RFC2409' is defined on line 381, but not referenced
>     '[RFC2409]   Harkins, D. and D. Carrel, "The Internet Key Exchange (...'
>
>
>
>