[6lowpan] Proposal for DISCUSS Editorials

[Carsten Bormann <[e-mail]>]

I'm proposing the following disposition of the editorial IESG  
comments that weren't in my previous message.
Again, quick feedback is useful.

Gruesse, Carsten


#################################
* Editorial 1

 From Gen-ART review by Joel Halpern:

         I don't know that I have ever seen a document before that  
says "thou
shalt not extend this."  (Section 5, last sentence before 5.1, "All  
headers used
in LOWPAN adaptation layer SHALL be defined in this format document.")

===> INTERPRET COMMENT
My view of this is that this is indeed the intention. Of course,
evolving this spec itself should be possible.  Note that this would
require some version management, which will need to be addressed by
bootstrapping.

#################################
* Editorial 2

         The fragmentation technique sends an offset that is in  
multiple of 8
bytes.  It would be sensible to say that all fragments except the  
last SHOULD
(MUST?) be multiple of eight bytes, so that the fragment offset works  
well.
(section 5.3)

===> ACCEPT COMMENT AND CHANGE TEXT
OLD:
    If an entire payload (e.g., IPv6) datagram fits within a single
    802.15.4 frame, it is unfragmented and the LoWPAN encapsulation
    should contain no fragmentation header.  If the datagram does not  
fit
    within a single IEEE 802.15.4 frame, it SHALL be broken into link
    fragments.  The first link fragment SHALL contain the first fragment
    header (defined by one-bit as the first two bits and a zero-bit as
    the third bit) shown below.

NEW:
    If an entire payload (e.g., IPv6) datagram fits within a single
    802.15.4 frame, it is unfragmented and the LoWPAN encapsulation
    should contain no fragmentation header.  If the datagram does not  
fit
    within a single IEEE 802.15.4 frame, it SHALL be broken into link
    fragments.  As the fragment offset can only express multiples of
    eight bytes, all link fragments for a datagram except the last one
    MUST be multiples of eight bytes in length.
    The first link fragment SHALL contain the first fragment
    header (defined by one-bit as the first two bits and a zero-bit as
    the third bit) shown below.

(This is a new MUST, but sensible implementations would have discarded
non-aligned non-final fragments anyway because of the non-overlap  
mandate.)

#################################
* Editorial 3

         At the beginning of section 10.1 on Encoding IPv6 Header  
fields, the
wording is slightly misleading.  The wording says "The following  
common IPv6
header values may be compressed from the onset..."  I would suggest  
instead "The
following IPv6 header values are expected to be common on 6lowPan  
networks, so
the HC1 header has been constructed to efficiently compress them from  
the
onset."

===> ACCEPT COMMENT AND CHANGE TEXT
OLD:
    By virtue of having joined the same 6LoWPAN network, devices share
    some state.  This makes it possible to compress headers even in the
    absence of the customary context-building phase.  Thus, the  
following
    common IPv6 header values may be compressed from the onset: Version
    ...
NEW:
    By virtue of having joined the same 6LoWPAN network, devices share
    some state.  This makes it possible to compress headers without
    explicitly building any compression context state; 6lowpan header
    compression therefore does not keep any flow state, but relies
    entirely on information pertaining to the entire link.  The  
following
    IPv6 header values are expected to be common on 6lowPan networks,
    so the HC1 header has been constructed to efficiently compress them
    from the onset: Version
    ...


#################################
* Editorial 4

Dan Romascanu:

Comment [2007-03-05]:
The following two Informative References do not seem to be used:

     [I-D.ietf-ipngwg-icmp-v3]
               Conta, A., "Internet Control Message Protocol (ICMPv6)  
for
               the Internet Protocol Version  6 (IPv6) Specification",
               draft-ietf-ipngwg-icmp-v3-07 (work in progress),
               July 2005.

    [I-D.ietf-ipv6-node-requirements]
               Loughney, J., "IPv6 Node Requirements",
               draft-ietf-ipv6-node-requirements-11 (work in progress),
               August 2004.

===> REMOVE UNUSED REFERENCES

#################################
* Editorial 5

Comment [2007-03-06]:
Section 3, last paragrpah:
The working group may pursue additional
    mechanisms as well.

Is this the right document to state a possible direction of a WG?

===> REMOVE SENTENCE

#################################
* HC editorial complex

Magnus Westerlund:

Discuss [2007-03-08]:

Section 10.1:

    By virtue of having joined the same 6LoWPAN network, devices share
    some state.  This makes it possible to compress headers even in the
    absence of the customary context-building phase. Thus, the following
    common IPv6 header values may be compressed from the onset: Version
    is IPv6; both IPv6 source and destination addresses are link local;
    the IPv6 interface identifiers (bottom 64 bits) for the source or
    destination addresses can be inferred from the layer two source and
    destination addresses (of course, this is only possible for  
interface
    identifiers derived from an underlying 802.15.4 MAC address); the
    packet length can be inferred either from layer two ("Frame Length"
    in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the
    fragment header (if present); both the Traffic Class and the Flow
    Label are zero; and the Next Header is UDP, ICMP or TCP.

Currently this is written such as that one get the impression that these
assumptions always will be true. Instead as it seems it should be  
interpret, in
case the fields has the following values gains in HC can be made.

===> SEE EDITORIAL 3 ABOVE.  COVERED.

The text is also confusing the reader if there exist a context state  
or not.
For example:

       Preliminary context is often required.  If so, it is highly
       desirable to allow building it by not relying exclusively on the
       in-line negotiation phase.  For example, if we assume there is
       some manual configuration phase that precedes deployment (perhaps
       with human involvement), then one should be able to leverage this
       phase to set up context such that the first packet sent will
       already be compressed.

===> STRIKE THIS PARAGRAPH.

There is also confusion about if several flows can be handled.  
Primarily due to
the following:

       Existing work assumes that there are many flows between any two
       devices.  Here, we assume that most of the time there will be  
only
       one flow, and this allows a very simple and low context flavor of
       header compression.

===> STRIKE PARAGRAPH

Please clarify that the compression is done totally without context  
and thus
can handle any number of flows.

===> COVERED (EDITORIAL 3 ABOVE)

Section 10.

Unfortuntate that this document wasn't announced on the ROHC WG list  
during its
WGL last call. Based on that the description seems somewhat to thin  
to be easily
implementable. I would propose that we delay the approval, update the  
draft and
send it for an explicit review in ROHC.

===> SORRY.  ROHC WG WAS AWARE ABOUT 6LOWPAN, BUT IT SHOULD HAVE BEEN
      ALERTED EXPLICITLY.  HARD TO FIX NOW.  NO NEED TO WAIT, THOUGH.

Lars Eggert:

Comment [2007-03-07]:
Agree with Magnus' points about the header compression specification.

===> COVERED (ABOVE).




_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan