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

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

Hello Alvaro

I’m available 8->11AM eastern every day next week but Thursday where it’s till 10 AM :)

Take care

Pascal

Le 18 sept. 2020 à 17:47, Alvaro Retana <[e-mail]> a écrit :


[Cutting the list a little.]

Pascal:

Hi!

I think we should talk live about this — if there’s time on the Interim (Inés?), then maybe we can do it there since the RPLv2 topic seems to be on the agenda.  Or we could do it before — give me a couple of options for next week.  It would be ideal to have you, Michael and one of the Chairs, at least, on the call — we can of course open the call to anyone once we figure out a time that works.

Thanks!

Alvaro.


On September 18, 2020 at 10:15:24 AM, Pascal Thubert (pthubert) ([e-mail]<mailto:[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]<mailto:[e-mail]>>
> Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; Routing Over Low power
> and Lossy networks <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Alvaro Retana
> <[e-mail]<mailto:[e-mail]>>; Ines Robles <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[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]<mailto:[e-mail]>> a écrit :
> >
> > On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
> >>
> >> Benjamin Kaduk <[e-mail]<mailto:[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]<mailto:[e-mail]>> . o O ( IPv6 IøT consulting )
> >> Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >
> >