Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-17.txt

From: Zach Shelby <[email-masked]>
Date: Mon, 13 Jun 2011 11:23:58 +0300

We missed a really useful set of WGLC comments from Esko Dijk during the nd-16 release editing (sorry!). This nd-17 release takes care of those comments, which helped to clarify next-hop determination of multicast addresses, a couple normative errors, and editorial nits. 

http://www.ietf.org/id/draft-ietf-6lowpan-nd-17.txt

Zach

Begin forwarded message:

> From: [email-masked]
> Date: June 13, 2011 11:20:31 AM GMT+03:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-nd-17.txt
> 
> A new version of I-D, draft-ietf-6lowpan-nd-17.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-6lowpan-nd
> Revision:	 17
> Title:		 Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)
> Creation date:	 2011-06-13
> WG ID:		 6lowpan
> Number of pages: 60
> 
> Abstract:
>   The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless
>   Personal Area Networks such as IEEE 802.15.4.  This and other similar
>   link technologies have limited or no usage of multicast signaling due
>   to energy conservation.  In addition, the wireless network may not
>   strictly follow traditional concept of IP subnets and IP links.  IPv6
>   Neighbor Discovery was not designed for non-transitive wireless
>   links.  The traditional IPv6 link concept and heavy use of multicast
>   make the protocol inefficient and sometimes impractical in a low
>   power and lossy network.  This document describes simple
>   optimizations to IPv6 Neighbor Discovery, addressing mechanisms and
>   duplicate address detection for 6LoWPAN and similar networks.
> 
> 
> 
> 
> The IETF Secretariat

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: [email-masked]
Date: Tue, 14 Jun 2011 10:44:36 +0200

Hi Zach,

Thanks for this new version.

I still have a comment about section 5.3.
In this section one can read that the RS must (actually there is no MUST, 
SHOULD, MAY in the text) be sent to the IPv6 All-Routers multicast address 
and the destination link-layer address may be some kind of all-routers 
anycast link-layer address.

However in section 10.2 the 2nd element of the list says that the RS can 
be sent unicast to the router with its link-local IPv6 address.
Don't you think that section 5.3 should mention the possibility to send a 
unicast RS in addition to the example provided in section 10.2?

Best regards,
Matthieu

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Jun 2011 03:01:22 -0700

> unicast RS in addition to the example provided in section 10.2?

A unicast RS is allowed in RFC 4861, so I think what you are proposing 
is just an editorial change to make the options clearer to those who 
haven't digested RFC 4861. Is my understanding correct?

    Erik

> Best regards,
> Matthieu
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: [email-masked]
Date: Tue, 14 Jun 2011 14:10:02 +0200

>haven't digested RFC 4861. Is my understanding correct?

Exactly.
If I'm right the behavior described in the example is defined neither in 
6LoWPAN ND section 5.3 nor in RFC 4861 section 6.3.7 even if RFC 4861 does 
not forbid it. IMHO it would be clearer to have all the options listed in 
section 5.3.

BTW the link to "Section 6.3.7" in section 5.3 is broken because it refers 
to 6LoWPAN ND instead of RFC 4861.

Matthieu