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

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

Hello Benjamin

 
> 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.

True; we considered the position of an implementer testing for MOP < 7 to decide if the flag was meaningful.
That implementer would have to populate the else statement and we preferred to give him instructions rather than have different implementations do different things.


> 
> 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

There was this traceability statement in https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-15#section-3 which is gone now.
I followed Alvaro's lead there; we removed it based on an interpretation of the "updates" that denotes a change in RFC 6550 implementations, which is not the case here. Using a reserved flag is not an "update" per this interpretation.

But yes, I see your point. 

> 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.

True.  We have created a file to store this kind of memory. I added your quote there, please see:

https://github.com/roll-wg/RPLv2/blob/main/README.md

I've been thinking about it so more but cannot find a better answer...

Many thanks!

Pascal

> 
> 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-2
> > > > 1.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.