[RTG-DIR] Rtg Dir review draft-ietf-6lo-rfc6775-update-13.txt

["Adrian Farrel" <[e-mail]>]

Hello, 

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft. 

Document: draft-ietf-6lo-rfc6775-update-13.txt
Note: I reviewed -13 (-14 came out half way through my review, but I kept right
on anyway).
Reviewer: Adrian Farrel
Review Date: 24th Feb 2018
IETF LC End Date: 6th Mar 2018
Intended Status: Standards Track 

Summary: 

I have concerns about this document and recommend that the Routing ADs discuss
these issues further with the authors. 
I also a long list of minor concerns and nits that I think should be resolved
before publication. 

Comments: 

The document is quite hard work. More cross-references would help, and bringing
the abbreviations to the top would also make things easier. But the main problem
was the trickle feed of how everything hangs together - it's all there, but you
have to read the entire document to get the whole picture.

==Major==

4.3

   With this specification, the Registration Unique ID is allowed to be
   extended to different types of identifier, as long as the type is
   clearly indicated.  For instance, the type can be a cryptographic
   string and used to prove the ownership of the registration as
   discussed in "Address Protected Neighbor Discovery for Low-power and
   Lossy Networks" [I-D.ietf-6lo-ap-nd].  In order to support the flows
   related to the proof of ownership, this specification introduces new
   status codes "Validation Requested" and "Validation Failed" in the
   EARO.

This seems fine, but I don't see how "the type is clearly indicated".

I think you also have to restate the uniqueness assumption in this new
context. Probably that uniqueness is required across {type, value}
(unless, of course, your answer to my first question is that type is 
embedded in value).  This possibly cuts into backward compatibility as
well?

See also 6.1/6.2

Furthermore, 7.1.2 says...

   A node that supports this specification MUST always use an EARO as a
   replacement to an ARO in its registration to a router.  This is
   harmless since the "T" flag and TID field are reserved in [RFC6775],
   and are ignored by a RFC6775-only router.  A router that supports
   this specification answers an ARO with an ARO and answers an EARO
   with an EARO.

...but this doesn't mention the "variation" of the RUID that might also
arise with the EARO. How will the RFC6775-only router handle these new
RUIDs and their "clearly indicated" types?

---

7.1.2

   One alternate way for a 6LN to discover the router's capabilities is
   to start by registering...

You went to a lot of trouble to define the E-flag. You then made the use
of the 6CIO (and hence the E-flag) only a SHOULD, and you defined an
alternate mechanism. (Note: you say "one alternate" implying there are
more!)

Choice is not good. It complicates the specification and the 
implementation. Why go there? Can't you settle on one mechanism and 
make it necessary and sufficient?

---

You create new registries in 10.1 and 10.2. You must tell the IANA what
allocation policies to use


==Minor==       

You have a number of cases of "SHOULD" and "RECOMMENDED" without
corresponding "MAY" clauses to describe variations. I think that I
could deduce the reasons (implementation decided to not do it) and
the results (function is not as rich), but you really should spell
these things out.

---

Would you consider folding Appendix C into the top of Section 2 so 
that it is possible to find the expansion of abbreviations more
easily?

---

RFC 6775 updates RFC 4944. Does this document also update RFC 4944?

---

I missed a discussion of Manageability and especially diagnosing faults.
It's not mandatory, but it would have been good. (There is a trickle of
info about policy configuration in 7.3).

---

The 2119 boilerplate should be updated to the most recent, viz.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

...which will require you add 8174 as a reference

---

Sect 2 expects the reader to be familiar with terms and concepts in a
long list of other documents. Doesn't that make them normative refs?

[RFC7102]
[RFC7228]
[RFC4861]
[RFC4862]
[RFC6606]
[RFC4919]
[RFC6775]
[I-D.ietf-ipv6-multilink-subnets]

---

Sect 2 has

   Extended LLN:  The aggregation of multiple LLNs as defined in
         [RFC4919], interconnected by a Backbone Link via Backbone
         Routers, and forming a single IPv6 MultiLink Subnet.

I'm not super-familiar with 4919, but a quick scan did not make it
obvious what you are referencing in that document.  "LLN" is not
mentioned. Nor is "aggregation" or "interconnect" (in this context).
There is some mention in 4.2 of "seamless integration": is that what
you are referencing?

---

Sect 2 has

   Registration:  The process during which a 6LN registers its
         address(es) with the Border Router so the 6BBR can serve as
         proxy for ND operations over the Backbone.

Do you mean s/Border/Backbone/ ?
Otherwise it seems strange that the 6LN registers with the 6LBR so that
the 6BBR can do something.

---

Sect 2

   Binding:  The association between an IP address with a MAC address, a
         port and/or other information about the node that owns the IP
         address.

This was hard to parse. Possibly you mean...

   Binding:  The association between an IP address, a MAC address, a
         port, and other information about the node that owns the IP
         address.

---

Sect 2

   Registering Node:  The node that performs the registration to the
         6BBR, which may proxy for the registered node.

Confusing!
The 6BBR is defined as the "proxy for the registration".
Now we appear to have:
- a node that needs to be registered
- a node that does the registration to the 6BBR
- the 6BBR (the proxy)
The final subclause of your text ("which may proxy for the registered
node") could be applied to the node that performs the registration or
to the 6BBR.

---

4.1

   The Extended ARO (EARO) deprecates the ARO and is backward compatible
   with it.  More details on backward compatibility can be found in
   Section 7.

   The semantics of the ARO are modified as follows:

Given the "deprecates" statement, you probably want...

   The semantics of the EARO are identical to the ARO with the following
   modifications:

---

4.2

   The Transaction ID (TID) is a sequence number that is incremented
   with each re-registration.

Who increments?

---

4.2

   The TID may also be used by the
   network to track the sequence of movements of a node in order to
   route to the current (freshest known) location of a moving node.

You don't need to track the sequence of movements in order to identify
the freshest known location. You only have to spot the most recent TID.
This makes a big difference to implementations: is there a need to track
the sequence or can an implementation just look for the most recent TID?

---

4.7

   If the registry in the 6LBR is saturated, then the LBR cannot decide
   whether a new address is a duplicate.  In that case, the 6LBR replies
   to a EDAR message with a EDAC message that carries a new Status Code
   indicating "6LBR Registry saturated" Table 1.  Note: this code is
   used by 6LBRs instead of Status 2 when responding to a Duplicate
   Address message exchange and passed on to the Registering Node by the
   6LR.  There is no point for the node to retry this registration
   immediately via another 6LR, since the problem is global to the
   network.  The node may either abandon that address, de-register other
   addresses first to make room, or keep the address in TENTATIVE state
   and retry later.

Three points:

"cannot" seems strong since the first occurrence of the duplicate might
already be in the registry.

de-registering an address to make room seems a risky business since some
other 6LR might grab the space.

Shouldn't the actions be at the 6LBR
- to notify the operator
- to clear out "old" entries from the registry (although that may require
  magic beyond housekeeping after Registration Lifetime expiration: 
  perhaps it could curtail the Delay state?)

---

5.

   The 6CIO is typically sent in a Router Solicitation (RS) message.
   When used to signal capabilities per this specification, the 6CIO is
   typically present in Router Advertisement (RA) messages but can also
   be present in RS, Neighbor Solicitation (NS) and Neighbor
   Advertisement (NA) messages.

I didn't find the two uses of "typically" gave me confidence to know
what to code.

---

6.1

   |   3   | Moved: The registration failed because it is not the      |
   |       | freshest.  This Status indicates that the registration is |
   |       | rejected because another more recent registration was     |
   |       | done, as indicated by a same RUID and a more recent TID.  |
   |       | One possible cause is a stale registration that has       |
   |       | progressed slowly in the network and was passed by a more |
   |       | recent one.  It could also indicate a RUID collision.     |

Do you think "Moved" is the best name to cover all of these 
possibilities?

But, anyway, how can you have a RUID collision by definition of a RUID?

---

6.1

                   The node SHOULD maintain the TID in a persistent
                   storage.

Unfortunate to push persistent storage requirements. But, since this is
a SHOULD, all processes are in place to support not storing across 
restarts. So why make anyone do it? Surely you could fall back to the
default handling without persistent storage.

---

6.2 

   Code:           The ICMP Code as defined in [RFC4443].  The ICMP Code
                   MUST be set to 1 with this specification.  An odd
                   value of the ICMP Code indicates that the TID field  
                   is present and obeys this specification.             

You're overloading the ICMP Code in an ugly way. But you knew that :-)
It would probably be more normal to steal the top bit so that allocation
of new codes can continue more normally. But failing that, I think you 
would be wise to make it so the IANA registry clearly shows that the odd
values must not be assigned in future (section 10.2).

---

It is not clear whether anything in App A and B is intended to be normative.
A clear statement would be helpful.

==Nits==

idnits shows three problems

 ** There is 1 instance of too long lines in the document, the longest one
     being 3 characters in excess of 72.

  == Missing Reference: 'Perlman83' is mentioned on line 1392, but not defined

  == Missing Reference: 'IEEEstd802154' is mentioned on line 1615, but not
     defined

The references are caused by you having a third references section. I've not
seen that before. Why not merge the sections as normal?

---

Document header

I suspect "cisco" should have a capital "C"

---

I think the document title should spell out "Neighbor Discovery" and
"IPv6 over Low-Power Wireless Personal Area Networks"

---

Sect 1

s/an IPv6 Low Power Networks/any IPv6 Low Power Network/

---

Sect 1

   to enable additional capabilities and enhancements such as:

s/such as/including/

---

You use "NS" in section 4, but don't expand it until 4.1

---

4.4 could very usefully point at 6.2 to help the reader parse the text.

---

Shouldn't the figure in 6.2 show the optional ND options as described in
4.4?

---

4.7 has "LBR" which should be "6LBR"

---

6.1

s/SLLAO option/SLLA option/ (twice)
s/The EARO option/The EARO/  (three times)

---

6.3

   This specification defines new capability bits for use in the 6CIO,
   which was introduced by [RFC7400] for use in IPv6 ND RA messages.

Say "...defines four new..." to save me having to work out which bits
are new.

---

6.3
   Routers that support this specification MUST set the "E" flag and 6LN
   SHOULD favor 6LR routers that support this specification over those
   that do not. 

s/6LR routers that support/a 6LR that supports/ 

---

8.

   This specification extends [RFC6775], and the security section of
   that standard also applies to this as well.

Don't think 6775 is an Internet Standard.
Suggest s/standard/document/.