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

From: gabriel montenegro <[email-masked]>
Date: Thu, 25 Jan 2007 18:22:12 -0800 (PST)

Thanks Samita for the review, and specially for making it clear that these
nits should not delay going to IESG.

Hopefully, we will go soon to IESG, but the chairs have not said anything
about this.

Chairs?

About your comments:

1. Not sure what to do here. Are you saying that parsing is somehow trickier now
   than it was before the header change? The WG adopted the new header cuz there
   was consensus that things would be better, not worse. Are you saying they are
   worse? Beyond this, being careful in the implementation about bit fields etc
   is, well, part of the implementation, so I'm not sure what to do here (or if
   we need to do anything). Perhaps if you suggest some text it'll be easier to see?

2. Not sure why we need to add yet another sub-title for such a short
   section. This is patterned after section 6 of:

        http://tools.ietf.org/html/rfc2464

   which itself does not have such sub-title.
   Besides, the paragraph before the diagram clearly states already
   that this is:
	"The Source/Target Link-layer Address option"

   which seems pretty explicit. Left it as it is.
3. reworded to "LoWPAN Broadcast" 

thanks,

-gabriel

----- Original Message ----
From: Samita Chakrabarti <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Wednesday, January 24, 2007 7:47:52 PM
Subject: 6lowpan-format-09

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 29 Jan 2007 17:59:29 -0800

Hi Gabriel,

Please see my comments in-line.

>    we need to do anything). Perhaps if you suggest some text it'll be easier

I actually like the new header changes. I particularly picked the
fragment sub-header because it has got 11bits, 10bits and 3 bits for
the first fragment. This
particular one is not 32bit-word aligned and parsing and casting etc.
will require some bit operations. In embedded systems at the
low-level,
this might be a common practice, but I was thinking if we could have
some sort of
text for the implementors in general. What do folks think about
something like the following ?

---
The fields and header segments, described in this document, are not
always byte-aligned or 32-bit word aligned. The implementors of this
document are responsible
for sending and processing the data on the wire according to the
specification for interoperability among different implementations.
----

>  which seems pretty explicit. Left it as it is.

If  purpose of this section is to describe mapping of an unicast
IPv6-address to IEEE802.15.4 link-layer address, then it is very
helpful if the first sentence says
that. ( like rfc2464). In that case, we can move the address
resolution text at the
end of the section.  Currently, it is a bit confusing.

Thanks for the prompt response and update.
-Samita

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]