Re: [Roll] turnon-8138 review

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

Dear all:

Many thanks to Rahul for his excellent review : )

I agree with Rahul that we are not modifying RFC 8138 but complementing it. We’re back to the long discussion on what “updates” means. Trust me, you do not enter that discussion, it is really a grey zone and caused very long threads for not much outcome AFAIK. For now I’d rather leave it as is because when people implement RFC 8138 it’s good that the RFC header points at this draft so the implementer implements them together. Note that https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-30 chose the same and passed IESG review with it.

I also agree that using MOP-ext is the way to go, and we’d need a flag from the device to indicate in which setting it is operating. Note that this creates a normative dependency => this draft cannot ship before MOP-ext. Note also that this is a “current setting” flag as opposed to a “capability” flag, so it would be good to enlarge a bit the wording in MOP-ext to cover that form of usage.

For the IP in IP, I agree it’s good to clarify. I provided text in https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-30#section-4.3 on how that happens. We can reference it in the next version of this draft. I placed similar text in annex of the RUL draft, see https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#appendix-A. I’ll try to push a fix today.

All the best,

Pascal

From: Roll <[e-mail]> On Behalf Of Rahul Arvind Jadhav
Sent: lundi 8 juillet 2019 04:26
To: Li Zhao (liz3) <[e-mail]>; [e-mail]
Cc: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] turnon-8138 review

Thanks Zhao, Please find my comment inline.

Section 5.4. “Rolling Back”, says, the administrator SHOULD make sure that all nodes have converged to the “T” flag reset before allowing nodes that do not support the compression in the network.
[RJ] How would a root know that all the nodes have accepted the T-reset? Doesn't this require use of capability flag ? Also I’m not sure if the same capability flag used before can be used here?
[LZ]Yes. This requires use of  capability flag. I think there is no capability flag before to identify the T-reset. One option is using reserving flag in DAO base object. Another option is leveraging draft-rahul-roll-mop-ext<https://datatracker.ietf.org/doc/draft-rahul-roll-mop-ext/>
[RJ] the point I wanted to convey is, you may need two flags if rolling back needs to be supported. Flag1 is Supports8138. Flag2 is Enabled8138. For rolling back and for nodes supporting 8138, these nodes need to inform the root with Enabled8138=0 and Supports8138=1 flag.
Secondly, the option you mentioned of using DAO base object for such flags may not be correct. These are target specific flags and a DAO object might carry multiple targets.