Subject: [rohc] Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 3 Sep 2009 06:47:01 -0700 (PDT)

The IESG has received a request from the Robust Header Compression WG 
(rohc) to consider the following document:

- 'IKEv2 Extensions to Support Robust Header Compression over IPsec 
   (ROHCoIPsec) '
   <draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-09-17. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15206&rfc_flag=0

---

From: "Robert Stangarone" <[email-masked]>
Date: Sun, 20 Sep 2009 10:45:57 -0700

All,

Sorry for my belated response. This last workweek didn't allow me time to
respond on the date requested.

Comments:

http://www.ietf.org/id/draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt

- 2.1.2.  ROHC Attribute Types,  Integrity Algorithm for Verification of
Decompressed Headers

"Upon receipt of the ROHC_INTEG attribute(s), the responder must select
exactly one of proposed algorithms and send the selected algorithm back to
the initiator."
	  
I believe the intent here is to converge on exactly one ICV algorithm. It
should be noted that the chosen value (i.e. exactly ONE ROHC_INTEG
attribute) is included in the N(ROHC_SUPPORTED) Notify message returned by
the Responder to the Initiator. It would be pointless to include more than
one, as the signaling of ROHC Channel Parameters is only a two message
exchange, and this is the second of two messages. 

- 4.  IANA Considerations, ROHC Attribute Types" registry

Would it be prudent to allocate some space in this registry for "Private
Use" values? Not sure how much we might need, or what they would be used
for.

Bob Stangarone

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The
IESG
Sent: Thursday, September 03, 2009 6:47 AM
To: IETF-Announce
Cc: [email-masked]
Subject: [rohc] Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2
Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to
Proposed Standard

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipse
c-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1520
6&rfc_flag=0

_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Emre Ertekin <[email-masked]>
Date: Sun, 20 Sep 2009 20:41:09 -0700

Hi Bob,

> exchange, and this is the second of two messages.

Yes, I agree.  I will account for your comment in the next iteration
of the draft.

> Use" values? Not sure how much we might need, or what they would be

I can go either way here. ;-)  Anyone else on this think we should
allocate values for "Private Use"?  If so, how many?

BR,
Emre