Subject: [rohc] ROHCoIPSec submitted and Document Write-Up

From: Carl Knutsson <[email-masked]>
Date: Tue, 24 Mar 2009 13:58:17 +0100

Hi all,

I have asked the IESG to publish the ROHCoIPSec drafts as RFCs. As
recommended in RFC4858 sending all three write-up to the rohc-list.

ROHCoIPSec framework consists of the following drafts:

draft-ietf-rohc-hcoipsec
draft-ietf-rohc-ikev2-extensions-hcoipsec
draft-ietf-rohc-ipsec-extensions-hcoipsec

I want to thank the authors Emre, Chris, Rohan, Carsten, Tero and
everyone in the WG that contributed to the ROHCoIPSec documents.

Best regards,

/Carl Knutsson (ROHC WG Chair)

> Document write-up for draft-ietf-rohc-hcoipsec
> 
>   (1.a) Who is the Document Shepherd for this document? Has the 
>           Document Shepherd personally reviewed this version of the 
>           document and, in particular, does he or she believe this 
>           version is ready for forwarding to the IESG for publication? 
> 	  
> 	  Carl Knutsson is the Document Shepherd. The document has
> 	  been personally reviewed by Document Shepherd and is ready
> 	  to be published as "Informational".
> 	  
>     (1.b) Has the document had adequate review both from key WG members 
>           and from key non-WG members? Does the Document Shepherd have 
>           any concerns about the depth or breadth of the reviews that 
>           have been performed? 
> 
> 	  Yes, it has been reviewed by members of both ipsecme and rohc
> 	  WGs. The Document Shepherd have no concerns about the
> 	  depth or breadth of the reviews.
> 	  
>     (1.c) Does the Document Shepherd have concerns that the document 
>           needs more review from a particular or broader perspective, 
>           e.g., security, operational complexity, someone familiar with 
>           AAA, internationalization or XML? 
> 
> 	  No concerns.
> 	  
>     (1.d) Does the Document Shepherd have any specific concerns or 
>           issues with this document that the Responsible Area Director 
>           and/or the IESG should be aware of? For example, perhaps he 
>           or she is uncomfortable with certain parts of the document, or 
>           has concerns whether there really is a need for it. In any 
>           event, if the WG has discussed those issues and has indicated 
>           that it still wishes to advance the document, detail those 
>           concerns here. Has an IPR disclosure related to this document 
>           been filed? If so, please include a reference to the 
>           disclosure and summarize the WG discussion and conclusion on 
>           this issue.
> 
> 	  No concerns.
> 
>     (1.e) How solid is the WG consensus behind this document? Does it 
>           represent the strong concurrence of a few individuals, with 
>           others being silent, or does the WG as a whole understand and 
>           agree with it? 
> 
> 	  There is a strong consensus behind the document.  
> 	  
>     (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
>           discontent? If so, please summarise the areas of conflict in 
>           separate email messages to the Responsible Area Director. (It 
>           should be in a separate email because this questionnaire is 
>           entered into the ID Tracker.)
> 
> 	  No conflicts or display of extreme discontent.
> 
>     (1.g) Has the Document Shepherd personally verified that the 
>           document satisfies all ID nits? (See 
>           http://www.ietf.org/ID-Checklist.html and 
>           http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
>           not enough; this check needs to be thorough. Has the document 
>           met all formal review criteria it needs to, such as the MIB 
>           Doctor, media type and URI type reviews? 
> 
> 	  Yes.
> 	  
>     (1.h) Has the document split its references into normative and 
>           informative? Are there normative references to documents that 
>           are not ready for advancement or are otherwise in an unclear 
>           state? If such normative references exist, what is the 
>           strategy for their completion? Are there normative references 
>           that are downward references, as described in [RFC3967]? If 
>           so, list these downward references to support the Area 
>           Director in the Last Call procedure for them [RFC3967]. 
> 
> 	  Yes, No.
> 	  
>     (1.i) Has the Document Shepherd verified that the document IANA 
>           consideration section exists and is consistent with the body 
>           of the document? If the document specifies protocol 
>           extensions, are reservations requested in appropriate IANA 
>           registries? Are the IANA registries clearly identified? If 
>           the document creates a new registry, does it define the 
>           proposed initial contents of the registry and an allocation 
>           procedure for future registrations? Does it suggest a 
>           reasonable name for the new registry? See [RFC5226]. If the 
>           document describes an Expert Review process has Shepherd 
>           conferred with the Responsible Area Director so that the IESG 
>           can appoint the needed Expert during the IESG Evaluation? 
> 
> 	  Yes. 
> 	  
>     (1.j) Has the Document Shepherd verified that sections of the 
>           document that are written in a formal language, such as XML 
>           code, BNF rules, MIB definitions, etc., validate correctly in 
>           an automated checker? 
> 
> 	  Yes.
> 	  
>     (1.k) The IESG approval announcement includes a Document 
>           Announcement Write-Up. Please provide such a Document 
>           Announcement Write-Up? Recent examples can be found in the
>           "Action" announcements for approved documents. The approval 
>           announcement contains the following sections: 
> 
>           Technical Summary 
> 
> 	  IP Security (IPsec) provides various security services for
> 	  IP traffic.  However, the benefits of IPsec come at the cost
> 	  of increased overhead.  This document outlines a framework
> 	  for integrating Robust Header Compression (ROHC) over IPsec
> 	  (ROHCoIPsec). By compressing the inner headers of IP
> 	  packets, ROHCoIPsec proposes to reduce the amount of
> 	  overhead associated with the transmission of traffic over
> 	  IPsec Security Associations (SAs).
>  
> 	     
>           Working Group Summary 
> 
> 	  The document represents rough consensus of the working group.
> 	  
>           Document Quality 
> 
> 	  The document have been reviewed extensively by both members
> 	  from the ipsecme and the rohc working groups. During the WG
> 	  Last-Call the document was reviewed by the committed WG
> 	  reviewers Robert A. Stangarone Jr. and Yoav Nir.
> 
> 
> Document write-up for draft-ietf-rohc-ikev2-extensions-hcoipsec
> 
>   (1.a) Who is the Document Shepherd for this document? Has the 
>           Document Shepherd personally reviewed this version of the 
>           document and, in particular, does he or she believe this 
>           version is ready for forwarding to the IESG for publication? 
> 	  
> 	  Carl Knutsson is the Document Shepherd. The document has
> 	  been personally reviewed by Document Shepherd and is ready
> 	  to be published as Proposed Standard.
> 	  
>     (1.b) Has the document had adequate review both from key WG members 
>           and from key non-WG members? Does the Document Shepherd have 
>           any concerns about the depth or breadth of the reviews that 
>           have been performed? 
> 
> 	  Yes, it has been reviewed by members of both ipsecme and
> 	  rohc WGs. The Document Shepherd have no concerns about the
> 	  depth or breadth of the reviews.
> 	  
>     (1.c) Does the Document Shepherd have concerns that the document 
>           needs more review from a particular or broader perspective, 
>           e.g., security, operational complexity, someone familiar with 
>           AAA, internationalization or XML? 
> 
> 	  No concerns.
> 	  
>     (1.d) Does the Document Shepherd have any specific concerns or 
>           issues with this document that the Responsible Area Director 
>           and/or the IESG should be aware of? For example, perhaps he 
>           or she is uncomfortable with certain parts of the document, or 
>           has concerns whether there really is a need for it. In any 
>           event, if the WG has discussed those issues and has indicated 
>           that it still wishes to advance the document, detail those 
>           concerns here. Has an IPR disclosure related to this document 
>           been filed? If so, please include a reference to the 
>           disclosure and summarize the WG discussion and conclusion on 
>           this issue.
> 
> 	  No concerns.
> 
>     (1.e) How solid is the WG consensus behind this document? Does it 
>           represent the strong concurrence of a few individuals, with 
>           others being silent, or does the WG as a whole understand and 
>           agree with it? 
> 
> 	  There is a strong consensus behind the document.  
> 	  
>     (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
>           discontent? If so, please summarise the areas of conflict in 
>           separate email messages to the Responsible Area Director. (It 
>           should be in a separate email because this questionnaire is 
>           entered into the ID Tracker.)
> 
> 	  No conflicts or display of extreme discontent.
> 
>     (1.g) Has the Document Shepherd personally verified that the 
>           document satisfies all ID nits? (See 
>           http://www.ietf.org/ID-Checklist.html and 
>           http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
>           not enough; this check needs to be thorough. Has the document 
>           met all formal review criteria it needs to, such as the MIB 
>           Doctor, media type and URI type reviews? 
> 
> 	  Yes.
> 	  
>     (1.h) Has the document split its references into normative and 
>           informative? Are there normative references to documents that 
>           are not ready for advancement or are otherwise in an unclear 
>           state? If such normative references exist, what is the 
>           strategy for their completion? Are there normative references 
>           that are downward references, as described in [RFC3967]? If 
>           so, list these downward references to support the Area 
>           Director in the Last Call procedure for them [RFC3967]. 
> 
> 	  Yes, No.
> 	  
>     (1.i) Has the Document Shepherd verified that the document IANA 
>           consideration section exists and is consistent with the body 
>           of the document? If the document specifies protocol 
>           extensions, are reservations requested in appropriate IANA 
>           registries? Are the IANA registries clearly identified? If 
>           the document creates a new registry, does it define the 
>           proposed initial contents of the registry and an allocation 
>           procedure for future registrations? Does it suggest a 
>           reasonable name for the new registry? See [RFC5226]. If the 
>           document describes an Expert Review process has Shepherd 
>           conferred with the Responsible Area Director so that the IESG 
>           can appoint the needed Expert during the IESG Evaluation? 
> 
> 	  Yes. 
> 	  
>     (1.j) Has the Document Shepherd verified that sections of the 
>           document that are written in a formal language, such as XML 
>           code, BNF rules, MIB definitions, etc., validate correctly in 
>           an automated checker? 
> 
> 	  Yes.
> 	  
>     (1.k) The IESG approval announcement includes a Document 
>           Announcement Write-Up. Please provide such a Document 
>           Announcement Write-Up? Recent examples can be found in the
>           "Action" announcements for approved documents. The approval 
>           announcement contains the following sections: 
> 
>           Technical Summary
> 	  
>           As part of the ROHCoIPsec framework, this document defines 
> 	  extensions to Internet Key Exchange version 2 (IKEv2) to 
> 	  signal ROHC parameters between IPsec peers.
> 
>  
>           Working Group Summary 
> 
> 	  The document represents rough consensus of the working group.
> 	  
>           Document Quality 
> 
> 	  The document have been reviewed extensively by both members
> 	  from the ipsecme and the rohc working groups. During the WG
> 	  Last-Call the document was reviewed by the committed WG
> 	  reviewers Robert A. Stangarone Jr. and Yoav Nir.
> 
> 
> Document write-up for draft-ietf-rohc-ipsec-extensions-hcoipsec.txt
> 
>   (1.a) Who is the Document Shepherd for this document? Has the 
>           Document Shepherd personally reviewed this version of the 
>           document and, in particular, does he or she believe this 
>           version is ready for forwarding to the IESG for publication? 
> 	  
> 	  Carl Knutsson is the Document Shepherd. The document has
> 	  been personally reviewed by Document Shepherd and is ready
> 	  to be published as a Proposed Standard.
> 	  
>     (1.b) Has the document had adequate review both from key WG members 
>           and from key non-WG members? Does the Document Shepherd have 
>           any concerns about the depth or breadth of the reviews that 
>           have been performed? 
> 
> 	  Yes, it has been reviewed by members of both ipsecme and
> 	  rohc WGs. The Document Shepherd have no concerns about the
> 	  depth or breadth of the reviews.
> 	  
>     (1.c) Does the Document Shepherd have concerns that the document 
>           needs more review from a particular or broader perspective, 
>           e.g., security, operational complexity, someone familiar with 
>           AAA, internationalization or XML? 
> 
> 	  No concerns.
> 	  
>     (1.d) Does the Document Shepherd have any specific concerns or 
>           issues with this document that the Responsible Area Director 
>           and/or the IESG should be aware of? For example, perhaps he 
>           or she is uncomfortable with certain parts of the document, or 
>           has concerns whether there really is a need for it. In any 
>           event, if the WG has discussed those issues and has indicated 
>           that it still wishes to advance the document, detail those 
>           concerns here. Has an IPR disclosure related to this document 
>           been filed? If so, please include a reference to the 
>           disclosure and summarize the WG discussion and conclusion on 
>           this issue.
> 
> 	  No concerns.
> 
>     (1.e) How solid is the WG consensus behind this document? Does it 
>           represent the strong concurrence of a few individuals, with 
>           others being silent, or does the WG as a whole understand and 
>           agree with it? 
> 
> 	  There is a strong consensus behind the document.  
> 	  
>     (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
>           discontent? If so, please summarise the areas of conflict in 
>           separate email messages to the Responsible Area Director. (It 
>           should be in a separate email because this questionnaire is 
>           entered into the ID Tracker.)
> 
> 	  No conflicts or display of extreme discontent.
> 
>     (1.g) Has the Document Shepherd personally verified that the 
>           document satisfies all ID nits? (See 
>           http://www.ietf.org/ID-Checklist.html and 
>           http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
>           not enough; this check needs to be thorough. Has the document 
>           met all formal review criteria it needs to, such as the MIB 
>           Doctor, media type and URI type reviews? 
> 
> 	  Yes.
> 	  
>     (1.h) Has the document split its references into normative and 
>           informative? Are there normative references to documents that 
>           are not ready for advancement or are otherwise in an unclear 
>           state? If such normative references exist, what is the 
>           strategy for their completion? Are there normative references 
>           that are downward references, as described in [RFC3967]? If 
>           so, list these downward references to support the Area 
>           Director in the Last Call procedure for them [RFC3967]. 
> 
> 	  Yes, No.
> 	  
>     (1.i) Has the Document Shepherd verified that the document IANA 
>           consideration section exists and is consistent with the body 
>           of the document? If the document specifies protocol 
>           extensions, are reservations requested in appropriate IANA 
>           registries? Are the IANA registries clearly identified? If 
>           the document creates a new registry, does it define the 
>           proposed initial contents of the registry and an allocation 
>           procedure for future registrations? Does it suggest a 
>           reasonable name for the new registry? See [RFC5226]. If the 
>           document describes an Expert Review process has Shepherd 
>           conferred with the Responsible Area Director so that the IESG 
>           can appoint the needed Expert during the IESG Evaluation? 
> 
> 	  Yes. 
> 	  
>     (1.j) Has the Document Shepherd verified that sections of the 
>           document that are written in a formal language, such as XML 
>           code, BNF rules, MIB definitions, etc., validate correctly in 
>           an automated checker? 
> 
> 	  Yes. 
> 	  
>     (1.k) The IESG approval announcement includes a Document 
>           Announcement Write-Up. Please provide such a Document 
>           Announcement Write-Up? Recent examples can be found in the
>           "Action" announcements for approved documents. The approval 
>           announcement contains the following sections: 
> 
>           Technical Summary 
> 
>           Integrating ROHC with IPsec (ROHCoIPsec) offers the combined
>           benefits of IP security services and efficient bandwidth
>           utilization. This document describes the IPsec extensions to
>           the Security Policy Database (SPD) and the Security
>           Association Database (SAD) required to support ROHCoIPsec.
> 	     
>           Working Group Summary 
> 
> 	  The document represents rough consensus of the working group.
> 	  
>           Document Quality 
> 
> 	  The document have been reviewed extensively by both members
> 	  from the ipsecme and the rohc working groups. During the WG
> 	  Last-Call the document was reviewed by the committed WG
> 	  reviewers Robert A. Stangarone Jr. and Yoav Nir.
> 
>