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

[Martin Duke <[e-mail]>]

Again, I don't understand the protocol evolution model here, but isn't the
coder *already* in a fix if she encounters an unknown MOP?

On Fri, Sep 18, 2020, 13:48 Pascal Thubert (pthubert) <[e-mail]>
wrote:

> It’s not an easy one Martin
>
> With this bit we cover a transition after which we reclaim the bits. So we
> want a time bomb.
>
> After the transition the thing signaled by the bit will be always on.
>
> For a number of reasons there will be a RPLv2 and that one we decided will
> have MOP7.
>
> The leaves 5 and 6 that can still be defined with the bits meaningful.
> Those may never be defined.
>
> The question is what the cider does today in his code for those value of
> MOP. We need to tell him something...
>
> Keep safe.
>
> Pascal
>
> Le 18 sept. 2020 à 19:44, Martin Duke <[e-mail]> a écrit :
>
> 
> So I think this update somewhat clarifies the meaning of the original
> text, but I am still somewhat concerned about that meaning. Perhaps I just
> don't understand how DIO versioning works.
>
> Are the MOP codepoints meant to represent different ways of parsing the
> DIO base object? It seems very odd to me that this document is describing
> behavior in any way for MOP 5 and up, as there is no IETF consensus on what
> these codepoints are going to represent. Is the intent of this language to
> avoid having to write in every future specification "nodes using this MOP
> MUST use RFC 8138 and the T bit is reserved."?
>
> On Fri, Sep 18, 2020 at 7:15 AM Pascal Thubert (pthubert) <pthubert=
> [e-mail]> wrote:
>
>> Hello Benjamin and Alvaro
>>
>> I published the latest to have a fresh reference point.
>>
>> There seems to be an agreement that
>> 1) we need to tell the implementer what to do when MOP ==7
>> 2) The changes are updating RFC 6550 formally.
>>
>> This is reflected in draft 15 as published.
>>
>> Please let me know if I mossed something!
>>
>> Take care,
>>
>> Pascal
>>
>> Pascal
>>
>> > -----Original Message-----
>> > From: Pascal Thubert (pthubert)
>> > Sent: vendredi 11 septembre 2020 21:17
>> > To: Benjamin Kaduk <[e-mail]>
>> > Cc: Michael Richardson <[e-mail]>; Routing Over Low power
>> > and Lossy networks <[e-mail]>; [e-mail]; Alvaro Retana
>> > <[e-mail]>; Ines Robles <[e-mail]>;
>> > [e-mail]; The IESG <[e-mail]>
>> > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
>> draft-ietf-roll-turnon-rfc8138-
>> > 14: (with DISCUSS and COMMENT)
>> >
>> > Now I’m unsure Michael and I agree anymore.
>> >
>> > What will today’s developer code?
>> >
>> > We ask him to test if mop is < 7
>> >
>> > What value will the developer place in his code if the test returns
>> false?
>> >
>> > If there is no code the Boolean will be uninitialized and the result
>> will depend
>> > on the type of variable and the compiler.
>> >
>> > Whatever the developer does the code will end up having a behavior,
>> > compression or not.
>> >
>> >  Leaving it to the implementation will have some people choose true and
>> > others false. This is not what we want.
>> >
>> > We want to control what the code does so we can expect it in the future
>> and
>> > build our backward compatibility based on that sure knowledge.
>> >
>> > Before the draft the default was no compression. Quite naturally since
>> initially
>> > it did not exist.
>> >
>> > Also we discussed on the ML that for RPLv2 all implementations MUST
>> support
>> > the compression.
>> >
>> > In which case it is a better default for a coder today to decide to use
>> the
>> > compression for mop 7, isn’t it?
>> >
>> > I hope I make the case right. Just think you’re coding it!
>> >
>> > Take care,
>> >
>> > Pascal
>> >
>> > > Le 11 sept. 2020 à 18:26, Benjamin Kaduk <[e-mail]> a écrit :
>> > >
>> > > On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
>> > >>
>> > >> Benjamin Kaduk <[e-mail]> wrote:
>> > >>> 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.
>> > >>
>> > >> Up to here, we agree.
>> > >>
>> > >>> 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.
>> > >>
>> > >> Tthat's exactly what we don't want to do.
>> > >>
>> > >> We are saying NOTHING about rfc8138 when MOP==7.
>> > >> Nor are we saying that the T-bit exists (or doesn't exist).
>> > >
>> > > That's not how I read:
>> > >
>> > >       For a MOP value of 7, the compression MUST be used by default
>> > >   regardless of the setting of the "T" flag.
>> > >
>> > >
>> > >> What behaviour is default and what behaviour is negotiated, and how
>> > >> it it negotiated, and how the results are turned on, would be up to a
>> > >> document that specifies MOP=7 (or larger mopex)
>> > >
>> > > What you describe here is more along the lines of what I expected.
>> > >
>> > > -Ben
>> > >
>> > >> As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
>> > >> change, we did this for IP_version==4 and IP_version==6.
>> > >> We specifically did not change it for IP_version==7 or 8.
>> > >>
>> > >> --
>> > >> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>> consulting )
>> > >>           Sandelman Software Works Inc, Ottawa and Worldwide
>> > >>
>> > >
>> > >
>>
>