Subject: [rohc] FW: Change proposal for "draft-ietf-rohc-tcp-field-behavior-04.txt"?

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 18 Apr 2005 15:18:17 +0200

ROHC-TCP folks,

As a response to some review comments from tcpm individuals, the
following change proposal will be sent along with the document,
when put in front of the IESG.

Rgds,
/Lars-Erik

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) 
Sent: den 18 april 2005 15:10
To: 'Allison Mankin'
Subject: Change proposal for
"draft-ietf-rohc-tcp-field-behavior-04.txt"? 

CHANGE #1: Section 2.1.1, IPv6 "Next Header"

OLD:  
      This field will usually have the same value in all packets of a
      packet stream.  It encodes the type of the subsequent header.
      Only when extension headers are sometimes present and sometimes
      not, will the field change its value during the lifetime of the
      stream.  The field is therefore classified as STATIC.
      The classification of STATIC is inherited from RFC 3095 [36].
      However, it should be pointed out that the next header field is
      actually determined by the type of the following header.  Thus,
      it might be more appropriate to view this as an inference,
      although this depends upon the specific implementation of the
      compression scheme.

NEW:  
      This field will usually have the same value in all packets of a
      packet stream.  It encodes the type of the subsequent header.
      Only when extension headers are sometimes present and sometimes
      not, will the field change its value during the lifetime of the
>     stream.  Whether or not such a change would cause the sequence
>     of packets to be treated as a new flow (for header compression)
>     is an issue for profile design.  ROHC profiles must be able to
>     cope with extension headers and tunnelling, but the choice of
>     strategy is outside the scope of this document.  The field is
>     therefore classified as STATIC, as in RFC 3095 [36].  However,
      it should be pointed out that the next header field is actually
      determined by the type of the following header.  Thus, it might
      be more appropriate to view this as an inference, although this
      depends upon the specific implementation of the compression
      scheme.

CHANGE #2: Section 2.1.1, IPv6 "Version"

OLD:  
      The version field states which IP version is used.  Packets
      with different values in this field must be handled by
      different IP stacks.  All packets of a packet stream must
      therefore be of the same IP version.  Accordingly, the field is
      classified as STATIC.

NEW:  
>     The version field states which IP version is used, and packets
>     with different values in this field must be handled as different
>     flows.  Accordingly, the field is classified as STATIC-DEF.

CHANGE #3: Section 2.1.2, IPv4 "Version"

OLD:  
      The version field states which IP version is used.  Packets
      with different values in this field must be handled by
      different IP stacks.  All packets of a packet stream must
      therefore be of the same IP version.  Accordingly, the field is
      classified as STATIC.

NEW:  
>     The version field states which IP version is used, and packets
>     with different values in this field must be handled as different
>     flows.  Accordingly, the field is classified as STATIC-DEF.

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