Re: [Roll] UNaware leaves

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

Continuing ...

All: Considering the efforts Michael placed in that review I invited him to coauthor.
We now use github to collaborate and the WIP is in https://github.com/roll-wg/roll-unaware-leaves/ 

Michael: Please see below

> section 6 is rather all over the place.
> I'd like subsection points, because we are going to need to refer to the sections,

I can propose this:

   6.  6LN Requirements to be a RPL-Unware Leaf  . . . . . . . . . .   9
     6.1.  Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . .   9
     6.2.  IPv6 Host Support of RPL Artifacts  . . . . . . . . . . .   9
       6.2.1.  Support of the HbH Header . . . . . . . . . . . . . .   9
       6.2.2.  Support of the Routing Header . . . . . . . . . . . .  10
       6.2.3.  Support of IPv6 Encapsulation . . . . . . . . . . . .  10

> and there will be 6man interaction?
> Could the whole section be named, "6LN Requirements to be a Unware Leaf".
> Can we get a 6man reviewer for this sooner?
> 

Renamed. 
Note that the dependencies on IPv6 do not change IPv6, just requires an IPv6-compliant support by the host.
Not sure we need 6MAN help for that.



> >   or not.  The flows below are RPL Non-Storing Mode examples.  In
> >   Storing Mode, the DAO ACK may not be present, and the DAO messages
> >   cascade from child to parent all the way to the DODAG Root.
> 
> Actually, isn't the K-flag behaviour this still an open issue in the WG?
> Or did we resolve this somewhere?  Last I recall it was in Rahul's big document,
> not in something we had adopted.

There was never really an issue. There is a trick in one open source implementation (Kontiki) for an end-to-end ack that was useful for their use case. But that is non-standard.
The RUL draft reminds the normal expectation of RPL, that is a hop by hop ack. As I said on the mike at an early WG meeting, if the parent acks it takes responsibility to progress the DAO.
If later the parent fails to progress the DAO, it should stop being a parent and poison to the child can use some other path to progress  the DAO towards the root. 
Once the DAO reaches the root, the address becomes reachable.


> 
> I think that 7.1, if it is general flow, shouldn't try to do storing and non-storing
> mode.  Either have two sections, or omit the differences in the general flow, and
> deal with the details in subsequent sections.
> 

I made a step, to be improved, by adding the storing mode flow

> I think that maybe the general flow should omit the backbone registration.
> Explain it all without a backbone, and then do it again with backbone.
> 

Removed the BBR for now

> >   This specification does not alter the operation of a 6LoWPAN ND-
> >   compliant 6LN, which is expected to operate as follows:
> 
> really... I thought that we were making it able to deal with RPL artifacts, as
> specified in section 6!!!

Which is as should already be. That's not even 6LoWPAN ND, that's IPv6 if you look at it.

> What is the specific signal that the 6LR can use to know that the host is an RAN
> rather than a RUL?

Yes we have text, maybe even repeated with terminology; e.g., 

"
         The 6LR advertises the
   Registered Address in DAO messages, if and only if it is triggered by
   an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a
   RUL.  If the 'R' flag is not set, then the Registering Node is
   expected to be a RAN that handles the reachability of the Registered
   Address by itself.
"

More tomorrow. I committed what I had up to here in github.

Take care,

Pascal