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
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
