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

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

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