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

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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
Sent: Friday, October 06, 2006 1:20 AM
To: i-d-announce@ietf.org
Cc: rohc@ietf.org
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.

	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 
i-d-announce-request@ietf.org 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:
	mailserv@ietf.org.
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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc