Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13

From: Geoff Mulligan <[email-masked]>
Date: Thu, 23 Sep 2010 17:01:15 -0600

We have been reviewing 6lowpan Neighbor Discovery for quite some time
and have feedback on the list and from implementors.

We will now start Working Group Last Call on:

http://tools.ietf.org/html/draft-ietf-6lowpan-nd-13

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

This is a two-week Working-Group Last-Call, ending on Friday, October 8,
2010 at 2359 UTC.

Please review the changes to the document carefully, and send your
comments to the 6lowpan list.  

	Thanks,
		geoff

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 24 Sep 2010 12:27:12 -0700 (PDT)

Hi Geoff,
  I read the document, I think it is in good shape and can be moved.
I listed the nits I found below.

Regards,

Behcet

Typos:

the duplicate address detection
      mechanism Specified in Section 8.2 
s/S/s

The re-registration of a address can be combined with Neighbor
   Unreachability Detection
s/a/an

in which case it has a different
   Length.  
s/L/l

Neighbor Solicitations from hosts as specified above in section
   Section 6.  
s/section/

the Neighbor Cache entry for
   the host as specified in section Section 6
s/section/
Additional protocol constants are defined in Section Section 4.
s/Section/

The use of 6LoWPAN and LoWPAN, sometimes in the same sentence is confusing.

----- Original Message ----
> From: Geoff Mulligan <[email-masked]>
> To: 6lowpan <[email-masked]>
> Sent: Thu, September 23, 2010 6:01:15 PM
> Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13
> 
> _______________________________________________
> 6lowpan  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 Sep 2010 23:59:44 +0200

I will need to read this in more detail and reply.  I now have a quick 
comment bothering me since some time.

Le 24/09/2010 01:01, Geoff Mulligan a écrit :
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd-13:

>    Registration:
>       The process during which a LoWPAN node sends an Neighbor
>       Solicitation message with an Address Registration option to a
>       Router creating a Neighbor Cache entry for the LoWPAN node with a
>       specific timeout.

This sounds as a NA (not NS) with a lifetime field.  I wonder why isn't 
it an NA.  It does not solicit anything but it advertises.

> Thus for 6LoWPAN Routers the Neighbor Cache
>       doesn't behave like a cache.  Instead it behaves as a registry of
>       all the host addresses that are attached to the Router.

This bothers me: it is not a cache but it is called a cache.

Alex

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 24 Sep 2010 15:27:58 -0700

Hi Geoff,

We have 9 companies who have implemented and interoperability tested
6LowPAN-ND-13.  This work is in the ZigBee IP effort targeting smart
metering applications.   

I am in favor of moving the document to Last Call.

There is another interoperability test event Oct. 4-8 but I am reasonably
confident the current draft is complete enough for Last Call.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Geoff Mulligan
Sent: Thursday, September 23, 2010 4:01 PM
To: 6lowpan
Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13

	Thanks,
		geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 24 Sep 2010 16:47:56 -0600

Don,
  This is good news.  It is great to have feedback from folks that have
actually done an implementation!

	geoff

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 25 Sep 2010 08:17:35 +0200

Hi Alex,

I can't comment on the cache/table, but at least on the NS/NA problem.

The NS/NA are not used as actual advertisements for the node, but instead as
a way to carry an extra "payload", in this case the ARO. The way they are
used now means if you had a 6lowpan-ND host send messages to a host which
isn't using 6lowpan-ND it won't break anything.

A big part of 6lowpan-ND is ensuring you don't have duplicate addresses. If
you send a NA with the address you want to use, a non 6lowpan-ND node may
just update its neighbor cache per standard RFC4861 processing. If this
address was in fact a duplicate this would be bad!

Using the NS means you will get an NA back immediately, but it will have no
6lowpan-ND options, so you know the node doesn't support 6lowpan-ND and to
try with someone else.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexandru Petrescu
Sent: September 25, 2010 12:00 AM
To: [email-masked]
Subject: Re: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13

Alex

---

From: Robert Cragie <[email-masked]>
Date: Sun, 26 Sep 2010 18:24:25 +0100

For the record, I would have preferred to see all the address 
registration information in the ARO  but I think it can be moved forward.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 24/09/2010 8:27 PM, Behcet Sarikaya wrote:
>> From: Geoff Mulligan<[email-masked]>
>> To: 6lowpan<[email-masked]>