Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
RFC 6282

Note: This ballot was opened for revision 15 and is now closed.

(Ralph Droms) Yes

(Jari Arkko) No Objection

Comment (2011-01-19 for -)
No email
send info
Ari Keränen reviewed this draft. His comments:


Missing "updates RFC4944" text.

Section 1

Abbreviations ND & MAC should be expanded.

Section 3.1.1.

First time "ECN" and "DSCP" are used. Could move the expanded versions and references from Section 3.2.1 to here.

        01:  64 bits.  The address is derived using context information
           and the 64 bits carried in-line.  Any bits of the IID not
           covered by context information are taken directly from the
           corrseponding bits carried in-line.  Any remaining bits are

If the context defines some of the same bits as the in-line data, are context bits always used (and in-line bits ignored)? That could be said more explicitly too.

Also: s/corrseponding/corresponding/

Section 3.2.4

Expand RIID.

    DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression

Should that be "DAM = 00"?

Section 4.3.1

  This specification introduces a range of well-known ports (0xF0Bx)

This is a bit strange way to express a port range, and the term "well-known ports" is already reserved for ports < 1024. You could say something like:

  This specification introduces a range of ports, 61616 - 61631 (0xF0B0 - 0xF0BF), that can be compressed more efficiently, using only 4 bits.

  Transport Layer Security (TLS) Message Integrity Check (MIC) that
  validates that the content is expected and checked for integrity.

"validates" and "is expected and checked" sound a bit strange here. Could use something like "makes sure" and "is what is expected and is checked"

Section 4.3.2

Expand PDU.

(Ron Bonica) No Objection

Comment (2011-01-19 for -)
No email
send info
I also support the GENART DISCUSS on the checksum

(Stewart Bryant) No Objection

Comment (2011-01-19 for -)
No email
send info
I support Russ' Discuss on the checksum.

The mandatory use of checksum in IPv6 is controversial amongst some IETF communities (particularly the community using UDP as a tunnel type). Either this controversy needs to be resolved, or  draft-ietf-6lowpan-hc needs to deal correctly with the c/s /no c/s case. It could of course do this by always carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say that there is no c/s.

(Gonzalo Camarillo) No Objection

(Lars Eggert) (was Discuss) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-01-16)
No email
send info
I found a few small points of house-keeping:


I would like to see "6LowPAN" expanded in the title, Abstract, and
Introduction. I think that you will find "6LowPAN network" includes


Section 2

   implementations MAY implement compression according to Section 10 of
   [RFC4944], but SHOULD NOT send packets compressed according to
   Section 10 of [RFC4944].

s/compression/decompression/  ?


Figure 2

You might replace
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5


The text in section 3.2.1 is correct and can be understood, but it 
took me several readings to be sure that the text actually matched the
figures. If the authors looked at this piece again and polished it, it
would help the document.


Section 3.2.2

   When the encapsulating header carries
   IPv6 addresses, bits for the source and destination addresses are
   copied verbatim from the source and destination addresses of the
   encapsulating IPv6 header.
"verbatim" is incorrect in this context. And, anyway, it is redundant -       
"copied" is adequate.


Section 3.2.2

I think this section could usefully include a reference to 
[IEEE 802.15.4]


A number of figures are not numbered, which is mildly inconsistent.


Section 4.2

   For the most part, the IPv6 Extension Header is carried verbatim in
   the bytes immediately following the LOWPAN_NHC octet, with two
   important exceptions: Length Field and Next Header Field.

"verbatim" again :-)
I think in this case you should use "unmodified"


Seciotn 4.2

      1: The Next Header field is elided and the next header is encoded
         using LOWPAN_NHC, which is discussed in Section 4.



Section 4.3.2

   A forwarding node MAY imply authorization from an incoming packet if
   the C bit is set.

I think you mean "infer" not "imply".

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) No Objection

Comment (2011-01-20 for -)
No email
send info
I support Russ's discuss regarding the checksum.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-01-10 for -)
No email
send info
This is a fine document. I have only a few comments.

1. According to Section 2, this document appears to update RFC 4944. However, the document header does not include "Updates: RFC 4944".

2. In Section 6, please add an informative reference for Transport Layer Security (TLS).

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-01-20 for -)
No email
send info
I support Russ's discuss.