I feel that we have reached consensus on the document and plan to
forward draft 9 to the IESG today.
Thanks certainly go to Gabriel for making the effort to write the
original document and take on the onerous task of editing and also to
David and Jonathan for the work on the new header encoding and to
everyone in the group for their comments and review.
Hopefully we will not have any significant issues come back from the
IESG or the IETF last call.
geoff
On Thu, 2007-02-01 at 13:37 -0800, dculler wrote:
> Are we getting close to bringing this to a close? There seems to be a
> "Finally I had a chance to read the latest version of the draft"
> phenomenon that doesn't result in any changes but also seems to keep
> the process open.
>
>
> ______________________________________________________________________
> From: gabriel montenegro [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 01, 2007 12:51 PM
> To: Samita Chakrabarti
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [email protected]
> Subject: Re: 6lowpan-format-09
>
>
>
> 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
