Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

Hi!

Jumping in here on the Updates/MOP 7 point.


The only reason we’re trying to treat MOP 7 differently is because we (the
WG) know that the mopex draft is coming…which is the future document that
will define what 7 really means.

However, we’re still not there…and the mopex draft should be the one
defining all the changes.

I think the easiest thing to do at this point is to ignore mopex, and the
knowledge that things will change in the future…because we still don’t know
exactly what that future will be…this extension should then simply be
defined as other extensions have been: applicable to all MOPs.  When mopex
comes we can deal with the respective Updates, changes to the registries,
etc.


Alvaro.



On September 10, 2020 at 4:07:54 PM, Benjamin Kaduk ([e-mail]) wrote:

Hi Pascal!

On Thu, Sep 10, 2020 at 12:18:48PM +0000, Pascal Thubert (pthubert) wrote:
> Hello Benjamin
>
> Many thanks for the depth of your review and the considerable amount of
time you must have spent on it!
>
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
> > We are not allocating them, but we are changing the RFC 6550 behavior
in the
> > presence of at least one of them (but are not currently claiming to
Update
> > 6550). I have some further thoughts in the COMMENT section, but I don't
> > think the current state is consistent enough to be approved as-is.
>
> As Michael said on this thread.
>
> You'll find that we had a mention that we update RFC 6550 till -07, e.g.,
https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-05
>
> This changed with "AD Review of draft-ietf-roll-turnon-rfc8138-07"

Ah, that would explain why I remembered seeing an "Updating RFC 6550"
section but couldn't find it in the -14!
> "
>
> 155 3. Updating RFC 6550
>
> [major] I don't think that a formal Update to rfc6550 is necessary.
> In general, a formal Update indicates (at least to me) that an rfc6550
implementation has to also support this specification. IOW, all RPL routers
will have to support the new flag to be compliant with rfc6550. Also,
rfc8138 did not formally Update rfc6550.
> "
>
> So on that one, I will ask you to talk to Alvaro (cc). I am still looking
for the final words on what "updates" means!
>
> I'm holding the publication till you and Alvaro agree on this item. For
the rest, let's see below:

With thanks to Michael for the explanation, I will quote a bit and reply
here since I am replying to the other bits, too:

% We are changing the RFC6550 behaviour in the presence of 0,1,2,3,4,5,6.
% But, we are leaving the meaning of this bit when MOP=7 UNDEFINED, to be
% defined in a future document.

Defining the behavior when the bit is set seems like fairly normal
procedures for allocating something from an IANA registry -- your
implementation knows that the flags are managed by the registry and what to
do if a bit is set that you don't support is well-specified. That applies
to MOPs 0..6; but the situation for MOP 7 seems slightly different. If we
were *just* leaving the bit undefined/free for reuse in that situation,
that is probably also something that we can do in a normal "allocate a bit
from an IANA registry" document without need for Updates. But that's not
all we're doing; we're also saying that if you see MOP==7, then you have to
use the 8138 header/compression/whatever-we-end-up-calling-it. Yet we are
*not* allocating MOP==7. So either we are changing the RFC 6550 semantics
for the DODAG Configuration Option or we are placing normative requirements
on some future document that does allocate MOP==7, and I think we have
significant experience to suggest that one RFC placing normative
requirements on future RFCs is not a reliable mechanism ... which makes me
want to go with the "updates 6550" option. Perhaps marking MOP==7 in the
registry as a placeholder with this doc as a reference could also work, but
it might make mopex a bit messier, procedurally.