Subject: [6lo] WG input and discussions request

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 03:04:39 +0000

Hi All:

According to the final IETF agenda, 6lo session will take place on Wed, March 5th in the afternoon session (2 hr slot):

1520-1620 GMT

Wednesday Afternoon Session II

Sovereign<http://tools.ietf.org/agenda/89/venue/?room=sovereign>

IAB

rfcform

[https://datatracker.ietf.org/images/color-palette-4x4.gif]RFC Format Design Team Update

No Agenda Submitted

Balmoral<http://tools.ietf.org/agenda/89/venue/?room=balmoral>

INT

6lo<https://datatracker.ietf.org/doc/charter-ietf-6lo/>

[https://datatracker.ietf.org/images/color-palette-4x4.gif]IPv6 over Networks of Resource-constrained Nodes

In next two weeks, please review the documents that are on LC and provide your comments. Also, please review the updated drafts that are recently posted :
http://datatracker.ietf.org/doc/draft-ietf-6lo-lowpanz/     [ Whether it has addressed your LC comments]
http://datatracker.ietf.org/doc/draft-ietf-6lo-lowpan-mib/ [ Please provide more comments]
http://datatracker.ietf.org/doc/draft-ietf-6lo-lowpan-mib/ [ Ditto]
http://datatracker.ietf.org/doc/draft-mariager-6lo-v6over-dect-ule/  [ Please read and provide comments]

And the two new individual drafts :
http://datatracker.ietf.org/doc/draft-rizzo-6lo-6legacy/
http://datatracker.ietf.org/doc/draft-savolainen-6lo-optimal-transmission-window/

Best regards,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 03:24:36 +0000

[SC>] Corrected list of drafts. See below.

http://datatracker.ietf.org/doc/draft-ietf-6lo-ghc/ [ Ditto]

Best regards,
-Samita

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Feb 2014 13:22:05 +0100

> http://datatracker.ietf.org/doc/draft-ietf-6lo-lowpanz/     [ Whether it has addressed your LC comments]

Hi,

I still have a couple of comments on -02, mostly editorial (see at end).

Technical:

           An IPv6 host MUST construct its link-local IPv6 address and routable
           IPv6 addresses from the NodeID in order to facilitate IP header
           compression as described in [RFC6282].

Hmm.  The rest of the document is careful to keep the road open to privacy addresses.
I think the document would improve if we clearly denominate “MAC-derived” and “non-MAC-derived” addresses.
It is fine to keep link-local addresses MAC-derived only.
Routable addresses should be able to be non-MAC-derived, and then the mechanics of RFC 6775 apply.
The document already seems to get this right, except:

           In route-over environments, IPv6 hosts MUST use [RFC6775] address
           registration.  [RFC6775] Duplicate Address Detection (DAD) MUST NOT
           be used, since the link-layer inclusion process of G.9959 ensures
           that a NodeID is unique for a given HomeID.

The latter is true for addresses constructed from node ids (i.e. MAC-derived) only.

Editorial:

          assignment.  It is described how to construct an IID from a G.9959

("it is described how to") try to avoid the passive form here, this is
not very clear.

           IPv6 packets MUST use G.9959 transmission profiles which support MAC
           PDU payload sizes of 150 bytes or higher, e.g. the R3 profile.
           G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes
           and the transmission speed is down to 9.6kbit/s.

(Make that comment parenthetical?  Is it or is it not possible to
carry LowpanZ on R1 and R2?)

           64 bit 802.15.4 address details MUST be ignored.  This document only
           specifies the use of short addresses.

Well, the MUST sounds a bit strange here.  What is intended is right:
There simply is no MAC-layer 64-bit address that could be used.
s/MUST be ignored/do not apply/?

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 25 Feb 2014 23:21:07 +0000

Hi Carsten,

Thanks a lot for the review comments on lowpanz.

For the technical point on supporting the  non-MAC-derived non-link-local  addresses, Lets ask Anders if  it is possible to generate a non-MAC-derived IP-address in Lowpanz network.  If it is possible, then it makes sense to support the non-MAC derived addresses.

Though, as you mentioned below -- it will then change the specification a bit by allowing RFC 6775 DAD for the non-MAC derived addresses. 

I agree with the suggested editorial changes that will make the spec clear.

Regards,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, February 25, 2014 4:22 AM
To: [email-masked]
Subject: Re: [6lo] WG input and discussions request

Hi,

Technical:

I think the document would improve if we clearly denominate "MAC-derived" and "non-MAC-derived" addresses.

Editorial:

("it is described how to") try to avoid the passive form here, this is not very clear.

(Make that comment parenthetical?  Is it or is it not possible to carry LowpanZ on R1 and R2?)

Grüße, Carsten

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