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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,

I will say a bit more inline, but want to note upfront that my primary
unease here is that we seem to be assigning some (partial) semantics to MOP
value 7 here (even though we do not specify full semantics for MOP value 7):

                              For a MOP value of 7, [RFC8138] MUST be
   used on Links where 6LoWPAN Header Compression [RFC6282] applies and
   MUST NOT be used otherwise.

yet there is no "trail of breadcrumbs" for someone to follow from "I want
to implement MOP 7" and end up at the sentence I quoted above.  A formal
Update to 6550 would provide such a trail, as would being listed as a
reference in the IANA registry for MOP value 7.  My current understanding
is that the only thing we have right now is "repeat this requirement in
whatever document ends up providing a full specification for MOP value 7",
and I don't think that relying on the IETF's collective memory is a great
way to enforce such a requirement -- we can and have in the past slipped up
and published RFCs that are inconsistent with requirements imposed by
previous ones.

On Tue, Nov 10, 2020 at 08:15:33AM +0000, Pascal Thubert (pthubert) wrote:
> Hello Benjamin:
>  
> > That said, and my apologies for a hazy memory coming back to this after a
> > couple months, in a year or N from now when mopex is finalized, how will
> > someone looking at mopex know to use RFC8138 on links where 6LoWPAN
> > Header Compression applies (and not use it otherwise)?  We are claiming in
> > the -14 of this document that:
> > 
> >                               For a MOP value of 7, [RFC8138] MUST be
> >    used on Links where 6LoWPAN Header Compression [RFC6282] applies and
> >    MUST NOT be used otherwise.
> > 
> > but I am not sure (or have forgotten) what the chain of references is supposed
> > to lead someone who is implementing RPL plus MOP=7 to the requirement to
> > use RFC 8138.  I don't think we should just rely on the mopex text to do so,
> > since we are trying to impose the requirement with this document (which
> > predates mopex by some time), and there's not anything (other than our
> > collective memories, of course) requiring mopex to remain consistent with
> > that requirement.
> 
> Just to be clear for the other readers: MOPext does not exist as a normative reference for this work.
> The only field that exists is the MOP field in the DIO and that field is 3 bits long, values 0..7.

Yes.

> The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> This is the spec that updates RPL and changes the IANA registry to indicate that 7 is not a MOP.

Not a MOP at all, or not a "normal" MOP that behaves like 0..6?

> There we have:
> 
> "
> 
> ...
> 
>   Anticipating future work to revise RPL relating to how the LLN and
>    DODAG is configured, this document changes the interpretation of the
>    [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
>    specific.  The MOP is described in [RFC6550] section 6.3.1.  The
>    Options Flags Registry is renamed, and applies to MOP values zero (0)
>    to six (6) only, leaving the flags reserved for MOP value seven (7).
> 
>    In addition, this document reserves MOP value 7 for future expansion.
> 
> ...
> 
> 11.3.  Change MOP value 7 to Reserved
> 
>    This document changes the allocation status of the Mode of Operation
>    (MOP) [ianamop] from Unassigned to Reserved.  This change is in
>    support of future work related to capabilities.
> "
> 
> So basically we tell the implementations from now on to test if MOP is 7, and in that case, the Options Flags are undefined. In other words, if MOP is 7, the stack must not use the option flags as if the MOP was <7. In fact, 7 is no more a MOP value but a reserved thingy that can be overloaded in the future. And yes, we intend to do just that in MOPExt.
> 
> Until that happens, implementations are at a loss if they encounter when a MOP field that is all ones. So we need to give them instructions to cope with the situation. This draft derives whether to use RFC 8138 from whether the 6LoWPAN compression applies to the link or not.

Yes, we are saying "if you see a MOP field that is all ones, do this".  To
me, that seems like we want to be listed as an additional reference for MOP
value 7 in the IANA registry.

> This will stay true forever, unless another RFC amends it. When/if that happens, the new RFC will have to consider backward compatibility with a legacy implementation that implements the above. 

It will stay true forever (until amended), but how does a new person making
an implementation know to find this document and do so?  [useofrplinfo]
says that MOP value 7 is special and needs dedicated handling, but it
doesn't say anything about using 8138 [on links where 6LoWPAN Header
Compression applies].  I'm missing the trail of breadcrumbs.

Thanks,

Ben

> Note that this line of thought applies to 3 flags, defined respectively in:
> - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
> - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
> 
> Keep safe!
> 
> Pascal
> 
> > 
> > Thanks,
> > 
> > Ben
> > 
> > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote:
> > > Hello Alvaro
> > >
> > > I uploaded both draft with the suggested update, please see
> > >
> > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17.
> > > txt
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx
> > > t
> > >
> > > Keep safe
> > >
> > > Pascal
> > >
> > > > -----Original Message-----
> > > > From: Alvaro Retana <[e-mail]>
> > > > Sent: jeudi 24 septembre 2020 17:49
> > > > To: Pascal Thubert (pthubert) <[e-mail]>
> > > > Cc: Benjamin Kaduk <[e-mail]>; The IESG <[e-mail]>;
> > > > draft-ietf- [e-mail]; Martin Duke
> > > > <[e-mail]>; Routing Over Low power and Lossy networks
> > > > <[e-mail]>; roll- [e-mail]; Michael Richardson
> > > > <[e-mail]>
> > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > > draft-ietf-roll-turnon-rfc8138-
> > > > 14: (with DISCUSS and COMMENT)
> > > >
> > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote:
> > > >
> > > >
> > > > Pascal:
> > > >
> > > > Hi!
> > > >
> > > > > Following the meeting last Monday and subsequent the update of
> > > > > useofrplinfo by Michael (thanks Michael!) I published a new
> > > > > version of the turnon RFC
> > > > > 8138 draft.
> > > > >
> > > > > The major changes are
> > > > > - removed the formal update to RFC 6550
> > > > > - refer to useofrplinfo as the justification why the flag is not
> > > > > defined for MOP 7
> > > > > - defined the operation in MOP 7 as compression on iff the Link
> > > > > uses 6LoPWAN HC.
> > > >
> > > > Thanks for these changes.
> > > >
> > > > Because we have to cycle useofrplinfo back through (when the WG is
> > > > done with it), I asked Ben/Martin to wait for that before coming
> > > > back to this document.  It'll make it easier than tracking multiple
> > > > changes. :-)
> > > >
> > > >
> > > > OTOH, I do have comments on the recent change:
> > > >
> > > > OLD>
> > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > > the
> > > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > >    zero (0) to six (6) only, leaving the flags reserved for MOP
> > > > value
> > > >    seven (7).  For a MOP value of 7, the bit in position 2 is
> > > > considered
> > > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN
> > > > Header
> > > >    Compression [RFC6282] applies and MUST NOT be used otherwise.
> > > >
> > > > NEW>
> > > >
> > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > > the
> > > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > > zero (0)
> > > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on
> > > > Links
> > > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT
> > > > be used
> > > >    otherwise.
> > > >
> > > >
> > > > Thanks!
> > > >
> > > > Alvaro.