Re: [6lo] Draft applicability for 6775bis

Dear all: 

FWIW, I also created a ticket https://trac.ietf.org/trac/6lo/ticket/20 to track the issue. 

Please let me know if the text below is OK (you may leverage the ticket); I'll time out and post by the end of week.

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 4 avril 2017 18:16
To: Erik Nordmark <nordmark@sonic.net>; Christian Huitema <huitema@huitema.net>; Lorenzo Colitti <lorenzo@google.com>
Cc: Brian Haberman <brian@innovationslab.net>; 6lo@ietf.org
Subject: Re: [6lo] Draft applicability for 6775bis

Dear all:

I retrofitted the text with minors editions as follows:
"

2.  Applicability

   The purpose of the Address Registration Option (ARO) option [RFC6775]
   and the Extended ARO (EARO) option that is introduced in this
   document is to facilitate duplicate address detection (DAD) for hosts
   and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the
   routers to reduce the need for sending multicast neighbor
   solicitations and also to be able to support backbone routers.

   In some cases the address registration can fail or be useless for
   reasons other than a duplicate address.  Examples are the router
   having run out of space, a registration bearing a stale sequence
   number (e.g. denoting a movement of the host after this registration
   was placed), a host misbehaving and attempting to register an invalid
   address such as the unspecified address [RFC4291], or the host using
   an address which is not topologically correct on that link.  In such
   cases the host will receive an error to help diagnose the issue and
   may retry, possibly with a different address, and possibly
   registering to a different 6LR, depending on the returned error.

   However, the ability to return errors to address registrations MUST
   NOT be used to restrict the ability of hosts to form and use
   addresses as recommended in Host Address Availability Recommendations
   [RFC7934].  In particular, this is needed for enhanced privacy, which
   implies that each host will register a multiplicity of address as
   part mechanisms like Privacy Extensions for Stateless Address
   Autoconfiguration (SLAAC) in IPv6 [RFC4941].  This implies that a 6LR
   or 6LBR which is intended to support N hosts MUST have space to
   register at least on the order of 10N IPv6 addresses.
"

I also removed the administrative rejection, the return codes are now as follows:

"
   +-------+-----------------------------------------------------------+
   | Value | Description                                               |
   +-------+-----------------------------------------------------------+
   |  0..2 | See [RFC6775].  Note that a Status of 1 "Duplicate        |
   |       | Address" applies to the Registered Address. If the Source |
   |       | Address conflicts with an existing registration,          |
   |       | "Duplicate Source Address" should be used instead         |
   |       |                                                           |
   |   3   | Moved: The registration fails because it is not the       |
   |       | freshest                                                  |
   |       |                                                           |
   |   4   | Removed: The binding state was removed. This may be       |
   |       | placed in an asynchronous NS(ARO) message, or as the      |
   |       | rejection of a proxy registration to a Backbone Router    |
   |       |                                                           |
   |   5   | Proof requested: The registering node is challenged for   |
   |       | owning the registered address or for being an acceptable  |
   |       | proxy for the registration                                |
   |       |                                                           |
   |   6   | Duplicate Source Address: The address used as source of   |
   |       | the NS(ARO) conflicts with an existing registration.      |
   |       |                                                           |
   |   7   | Invalid Source Address: The address used as source of the |
   |       | NS(ARO) is not usable on this link, e.g. it is not        |
   |       | topologically correct                                     |
   |       |                                                           |
   |   8   | Invalid Registered Address: The address being registered  |
   |       | is not usable on this link, e.g. it is not topologically  |
   |       | correct                                                   |
   +-------+-----------------------------------------------------------+
"

Does that work?

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian Haberman
Sent: mardi 4 avril 2017 16:42
To: 6lo@ietf.org
Subject: Re: [6lo] Draft applicability for 6775bis

On 4/4/17 10:02 AM, Suresh Krishnan wrote:
> Hi Dave,
> 
>> On Mar 29, 2017, at 1:47 PM, Dave Thaler <dthaler@microsoft.com>
>> wrote:
>> 
>> Any issue with a standards track document having a normative 
>> reference to a BCP?
> 
> No issues that I know of. The downref rules seem to be pointing
> *from* Standards track and BCP documents *to* lower maturity level 
> documents as per RFC3967. Just to be safe, I can still call this out 
> in the IETF last call if the WG decides to go that way.

Right. ST and BCP are at the same level, so there are no down-ref issues with a normative reference. Those issues arise when ST or BCP documents normatively reference Info and Experimental documents.

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo