Subject: [6lowpan] 6lowpan-format-09

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 24 Jan 2007 19:47:52 -0800

Hi Gabriel and all,

Finally I had a chance to read the latest version of the draft. It
looks good with
the new style of format.

A few minor  comments for the authors' consideration:

1)  Section 5.3 - the fragmentation format has 3bits + 10bits + 11bits
fields for
    first fragment sub-header and 3+10+11+8 for the subsequent fragments.
    Defining data structure, parsing and casting will require some
clever bit-field
    operations. I wonder if the fragmentation part has been
implemented and if the
    document can say a cautionary word about any byte alignment issues that
    the implemntors should take care in the implementation as the fragmented
    packet will appear on the wire. For example, implementation A's compiler
    puts a byte after the first-fragment declaration and before the
data, while implemention B does not do any padding.

2) Section 8 - Unicast address mapping. The second paragraph actually refers to
   SLLA/TLLA option from RFC2461. It is a bit confusing for the section heading,
   please add another sub-heading before this paragraph:
       8.1 Source and Destination Link Layer Address Option mapping

3) Section 11.1 Lowpan-BCO option
    Should we re-word the section header as "LowPan Broadcast
(LOWPAN_BCO)"  or similar ?
Why do we call this an "option" ? We are not calling mesh-header or
fragment-header
as options.

   Also, do we add the sequence number in order to avoid broadcasting duplicate
   packets from the same sender or originator in mesh? Please add a line on why
   we are adding the sequence number in this case.

Sorry for the late review, but these issues do not stop this draft to
move forward for
the AD review. Nice job!

Regards,
-Samita

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