Transmission of IPv6 Packets over IEEE 802.15.4 Networks
draft-ietf-6lowpan-format-13

(Updated with comments from Gen-ART review)

> 5.3.  Fragmentation Type and Header

The datagram tag (used for fragment reassembly) cycles after
1024 values, and the reassembly timeout is 60 seconds.
I'd like to see a calculation that the tag will never cycle
in less than 60 seconds. That doesn't seem like a long
time for sending a thousand packets. Maybe ZigBee is
just plain slow?

> 10.  Header Compression
>
>   There is much published and in-progress standardization work on
>   header compression. 

I'd like to see a few words about why ROHC is inapplicable.

>      Traffic Class and Flow Label (bit 4):
>         0: not compressed, full 8 bits for Traffic Class and 20 bits
>            for Flow Label are sent

What's the rationale for not compressing them? They are identical
in all packets of a given flow, so ideal candidates for compression.

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.")
        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)
        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."

I trust my predecessor's review for this sort of document, although I haven't reviewed it myself.  Thus I'm voting no objection.

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.

Agree with Magnus' points about the header compression specification.

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?

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.