Re: [Iot-directorate] [6lo] Iotdir last call review of draft-ietf-6lo-backbone-router-13

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dominique:

Many thanks for your great review! Considering its width and breadth, I published -14 for that review alone.
Diffs available here:  https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-14

Continuing from 3.4


	
> 3.4
> “Addresses in a LLN … must be registered … “. Is the use of lowercase “must”
> intended? “Over the LLN, Binding Table management is as follows:” 
> Sorry to sound stupid, but the list of actions does not include the initial registration.
> Likewise, the transitions between the Tentative, Reachable or Stale 
> states are not described fully, left to the reader to imagine. The 
> tone of voice of the Binding Table management is narrative. Why is RFC2119 language not used?
> After reading section 9, it occurred to me that this description might 
> just be a preview of section 9. If true, please state this explicitly 
> and add a forward reference.

Yes, section 3 is just an overview, intended to be so to provide a general view before the hard spec.
As a proposal, does it help if section 3 starts as follows:
"

3.  Overview

   This section and its subsections present a non-normative high level
   view of the operation of the 6BBR.  The next sections cover the
   normative part.  Figure 1 illustrates a backbone link that federates
   a collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs
   providing proxy-ND services to their attached LLNs.

"
I removed the few uppercase 

> 5
> “If this registration is”. Not sure what “this” refers to. Was this 
> piece of text moved around?

Probably. Reshuffled and now it looks like:

"
  When a 6LBR is present, the 6BBR uses an EDAR/EDAC message exchange
   with the 6LBR to check if the new registration corresponds to a
   duplication or a movement.  This is done prior to the NS(DAD)
   process, which may be avoided of the 6LBR already maintains a
   conflicting state for the Registered Address.

   If this registration is duplicate or not the freshest, then the 6LBR
   replies with an EDAC message with a status code of 1 ("Duplicate
   Address") or 3 ("Moved"), respectively.
"

> 
> 7.
> “Global including Unique Local addresses”
> Why “including”? Aren’t they disjoint ranges?

That's unclear to me since RFC 4291 does not seem to specify the boundaries of the global unicast address range when the IID is 64bits. OTOH RFC 4193 does not guarantee ULAs to be unique. So...

s/including/and/

> 9.
> How does Section 9 “Creating and Maintaining a Binding” articulate 
> with Section
> 3.4 “The Binding Table”? Is 3.4 just a preview (hence the narrative 
> style)? In which case, a forward reference from 3.4 to 9 would be useful.

Yes and yes.

> 
> 9.2
> “An NS(DAD) with no EARO or with an EARO that indicates a duplicate If 
> the Registration Lifetime is of a long duration, …” Cut&Paste error?

Yes, removed one line that ended up copied there from elsewhere.
Weird 😊


> # Nits:

- 3 Overview: “In the case, the co-existing function” -> “Any such co-existing function”

I could not find that one ???


For the other nits, the easiest is probably to go through https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-14

I'd appreciate that you look at the diffs and come back if I failed to address the nit properly.

Again, a great many thanks!

Pascal