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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 19 September 2020 02:04 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2B3A0FCB; Fri, 18 Sep 2020 19:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.835
X-Spam-Level:
X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMjI9pkNO7GZ; Fri, 18 Sep 2020 19:04:56 -0700 (PDT)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0871C3A0B06; Fri, 18 Sep 2020 19:04:55 -0700 (PDT)
Received: from dooku.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 37CBD1F4A4; Sat, 19 Sep 2020 02:04:54 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1FEF81A022D; Fri, 18 Sep 2020 22:04:53 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Martin Duke <martin.h.duke@gmail.com>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>, "roll-chairs\@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "draft-ietf-roll-turnon-rfc8138\@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, The IESG <iesg@ietf.org>, Alvaro Retana <aretana.ietf@yahoo.com>
In-reply-to: <CAM4esxQpcWROj9mMd3iUXr1EF8kvoF8Zmq-w4BPFVW+BtDU93w@mail.gmail.com>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <17053.1599841430@localhost> <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com> <E8B2CE91-7FEE-4728-A280-935B69EF3E91@cisco.com> <CAM4esxQpcWROj9mMd3iUXr1EF8kvoF8Zmq-w4BPFVW+BtDU93w@mail.gmail.com>
Comments: In-reply-to Martin Duke <martin.h.duke@gmail.com> message dated "Fri, 18 Sep 2020 14:02:50 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 18 Sep 2020 22:04:53 -0400
Message-ID: <117497.1600481093@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/XEylvS7VG_hItoq8fAPOwHJI3SA>
X-Mailman-Approved-At: Fri, 18 Sep 2020 22:32:26 -0700
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2020 02:04:58 -0000

Martin Duke <martin.h.duke@gmail.com> 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  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [