Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3095bis-framework-02.txt

From: [email-masked]
Date: Thu, 05 Oct 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Robust Header Compression Working Group of the IETF.

	Title		: The RObust Header Compression (ROHC) Framework
	Author(s)	: L. Jonsson, et al.
	Filename	: draft-ietf-rohc-rfc3095bis-framework-02.txt
	Pages		: 37
	Date		: 2006-10-5
	
The RObust Header Compression (ROHC) protocol provides an efficient,
   flexible and future-proof header compression concept. It is designed
   to operate efficiently and robustly over various link technologies
   with different characteristics.

   The ROHC framework, along with a set of compression profiles, was
   initially defined in RFC 3095. To improve and simplify the ROHC
   specifications, this document explicitly defines the ROHC framework
   separately, and thus replaces the framework specification of RFC
   3095.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-framework-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-rohc-rfc3095bis-framework-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-rfc3095bis-framework-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Sarkar, Biplab" <[email-masked]>
Date: Tue, 17 Oct 2006 23:37:22 +0530

L-E,

I have gone through the document
draft-ietf-rohc-rfc3095bis-framework-02.txt.
The document looks fine. I have a few questions which I am putting down
below.

[1] 5.1.2 - I see the mention of the per-channel parameters for link
layer negotiations.  The attribute "FEEDBACK_FOR" seems to be a new one
which is not there even in RFC3095 or in RFC3759. I believe it is an
implicit requirement which might have evolved from RFC3759, but this
requires more explanation.
- Can we get some more details about the range of the values that would
be negotiated here? 
- BTW are we planning to define some guidelines as to how the under
layer is going to define each ROHC channel? 
- Is a non negative integer enough to capture this feedback channel?   
- In case multiple feedback channels shares one channel, how will the
compressor de-multiplex the feedback pkts? 

[2] Do we need to capture the general behavior when CRC checks fails? I
was wondering if it was right to ignore a S-NACK/NACK packet even though
the CRC check fails? [RFC3095:5.7.6.4] Since the link was not good the
decompressor went out of sync and was sending a S-NACK/NACK, Now the
feedback pkt might get corrupted and the optional element CRC might
force us to discard this pkt. I think we should ignore a feedback ACK
and its subsequent context updating behavior if the CRC check fails. But
a NACK/SNACK should be always accepted. 
 
[3] A general question. Why do we have both CRC-7 and CRC-8 algo? Why
not just one of them?

[4] Is there any strict need for all future variants of the rohc
profiles to be back ward compatible? Since we are negotiating the entire
16-bit integer I don't see any direct need for that. 

Thanks
Biplab

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 1:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3095bis-framework-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Robust Header Compression Working Group
of the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-framework
-02.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-rohc-rfc3095bis-framework-02.txt".
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 18 Oct 2006 08:39:33 +0200

Biplab,

Thanks for the review, responses inline...

/L-E

> layer negotiations.  The attribute "FEEDBACK_FOR" seems to be
> a new one which is not there even in RFC3095 or in RFC3759.

This parameter is defined in exactly the same way in RFC 3095.

> layer is going to define each ROHC channel?

How to realize a ROHC channel is out of scope for this specification.
Guidance can be found in 3759, I do not think more than that can be
said on a general level, and we have RFC 3241 as an example.

> - Is a non negative integer enough to capture this feedback

This is up to the link layer to specify.

> - In case multiple feedback channels shares one channel, how
> will the compressor de-multiplex the feedback pkts?

A ROHC channel can only serve as one single ROHC feedback channel.

> [2] Do we need to capture the general behavior when CRC
> checks fails? 

This is not at all specified at the framework level. CRC's on
feedback are not even defined at the framework level.

> [3] A general question. Why do we have both CRC-7 and CRC-8 algo?
> Why not just one of them? 

They serve different purposes, thus they have different coverage.
The CRCs are as those used by RFC 3095.

> profiles to be back ward compatible? Since we are negotiating
> the entire 16-bit integer I don't see any direct need for that.

No, there is no such requirement on profiles, but "new variants"
are supposed to serve the same purpose.