Re: [IPsec] COMMENT: <draft-ietf-ipsecme-roadmap-09.txt>

["Frankel, Sheila E." <[e-mail]>]

We just submitted an updated version (-10) of the IPsec/IKE Roadmap doc. 
In accordance with Sean's recommendations, we addressed Tim Polk's comments as follows:

> Comment:
> (1) I understand that this is a forklift upgrade for RFC 2411, so the usual 
> "Changes Since ..." section would not be helpful.  However, this document 
> has a very similar title and does obsolete 2411 if approved.  Perhaps a few
> sentences in the intro to describe that relationship would be useful!

The original intro includes:
   This document is a snapshot of IPsec- and IKE-related RFCs.  It
   includes a brief description of each RFC, along with background
   information explaining the motivation and context of IPsec's
   outgrowths and extensions.  It obsoletes the previous IPsec Document
   Roadmap [RFC2411].

Added the following:
   The obsoleted IPsec roadmap [RFC2411] briefly described the
   interrelationship of the various classes of base IPsec documents.
   The major focus of [RFC2411] was to specify the recommended contents
   of documents specifying additional encryption and authentication
   algorithms.

> (2) RFC 5282 should be added to the list of base documents in section 
> 4.1.2, IKEv2.  As noted in section 5.4, 5282 added the capability to negotiate
> combined mode algorithms to IKEv2.

IKEv2 already has the capability to negotiate combined mode algs for use 
in ESP/AH. RFC 5282 adds the capability to use combined mode algs for 
IKEv2's own traffic. This is one of a number of add-ons; it is not part 
of the base IKEv2. 

> (3) Section 5.4.3 is misplaced.  GMAC is an Integrity protection algorithm 
> and should appear in section 5.3. This will necessitate forward pointers 
> to section 5.4, since it is based on a combined mode algorithm, but it does 
> not fit with the other algorithms in 5.4 which are providing both encryption 
> and integrity-protection.

As stated in Section 5.4.3, GMAC has 2 versions: an integrity protection 
alg for AH, and a combined mode alg with null enc for ESP. We chose to 
place it with the combined mode algs, but mentioned it in Section 5.3 
(the intro section for integrity protection algs).

> (4) In section 5.2.1, last sentence of the first paragraph:
>                                                                               
> This number (the value 11 for ESP_NULL) is found on the IANA registries 
> for both IKEv1 and IKEv2, but it is not mentioned in this RFC.
> 
> "this RFC" is ambiguous - I gather the authors meant RFC 2410 (since the
> value is clearly mentioned in *this* RFC).  I suggest:
> 
> s/this RFC/[RFC2410]/

DONE

Sheila and Suresh
____________________________________
From: Sean Turner [[e-mail]]
Sent: Thursday, August 12, 2010 12:15 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: COMMENT: <draft-ietf-ipsecme-roadmap-09.txt>

The state of this document is now "Approved: point raised - write up
needed".

I'd like the authors to generate a new version that address #1 and #4.

I don't think we should do #2 or #3.  They are comments not discusses
so we don't have to get him to agree to us not doing them.

I'll be watching for the new version.

spt