forgot one more thing. on #3, good point about explaining the sequence number (actually, Ian had suggested this, but it fell through the cracks). This is what it looks like now:
11.1. LoWPAN Broadcast Additional mesh routing functionality is encoded using a routing header immediately following the Mesh header. In particular, a broadcast header consists of a LOWPAN_BC0 dispatch followed by a sequence number field. The sequence number is used to detect duplicate packets (and hopefully suppress them). -gabriel ----- Original Message ---- From: gabriel montenegro <[EMAIL PROTECTED]> To: Samita Chakrabarti <[EMAIL PROTECTED]> Cc: [email protected]; [EMAIL PROTECTED] Sent: Thursday, January 25, 2007 6:22:12 PM Subject: [6lowpan] Re: 6lowpan-format-09 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 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
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
