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

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

Dear all

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/

There is also a HTML versions available at:
https://www.ietf.org/id/draft-ietf-roll-turnon-rfc8138-16.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-16

Please let me know if there is some issue left with this!

Keep safe,

Pascal



> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: samedi 19 septembre 2020 04:05
> To: Martin Duke <[e-mail]>; Pascal Thubert (pthubert)
> <[e-mail]>; Pascal Thubert (pthubert)
> <pthubert=[e-mail]>; Benjamin Kaduk <[e-mail]>;
> Alvaro Retana <[e-mail]>; [e-mail]; Routing Over
> Low power and Lossy networks <[e-mail]>; Ines Robles
> <[e-mail]>; [e-mail];
> The IESG <[e-mail]>; Alvaro Retana <[e-mail]>
> Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-
> 14: (with DISCUSS and COMMENT)
> 
> 
> Martin Duke <[e-mail]> wrote:
>     > 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?
> 
> YES, but, for an unknown MOP, they can become an RPL-aware leaf.
> However, they can't if they don't know if they are allowed to turn on 8138 or
> not. (or maybe forbidden from having it off!) For almost any other control
> plane option, it wouldn't matter, but this is actually a dataplane control option.
> 
> ** Perhaps I'm being too anal about saying that MOP==7 that 8138 action
> should not be
> ** defined here, but by a future document.
> 
> I'm actually now convinced I am.
> I think it's fine to say that for MOP==7, one should assume 8138 is turned on,
> for media on which it makes sense.
> 
> 8138 is afterall, a 6lowpan thing, and RPL can run on other media!
> 
> Part of the issue is that the *mopex* document assumes that MOP==7 will
> mean that there is a mopex. (as I recall).
> 
> 
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>