Samita, Thanks for the proposed text. I still don't think there's much benefit as it says little more than "please implement with care".
My opinion on these is unchanged. Any others? -gabriel ----- Original Message ---- From: Samita Chakrabarti <[EMAIL PROTECTED]> To: gabriel montenegro <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Sent: Monday, January 29, 2007 5:59:29 PM Subject: Re: 6lowpan-format-09 Hi Gabriel, Please see my comments in-line. > 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? > 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. ---- > 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. > 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 > > ----- Original Message ---- > From: Samita Chakrabarti <[EMAIL PROTECTED]> > To: gabriel montenegro <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [email protected] > 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 protected] https://www1.ietf.org/mailman/listinfo/6lowpan
