Re: [Roll] Martin Duke's Discuss on draft-ietf-roll-turnon-rfc8138-12: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 September 2020 01:32 UTC

Return-Path: <mcr+ietf@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 419633A0C46; Wed, 2 Sep 2020 18:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 4xIL4E8pEQ1Q; Wed, 2 Sep 2020 18:32:48 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE603A0CDD; Wed, 2 Sep 2020 18:32:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 06726389AB; Wed, 2 Sep 2020 21:11:38 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rP7Ij2KtOJsy; Wed, 2 Sep 2020 21:11:37 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB8B7389AA; Wed, 2 Sep 2020 21:11:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7B47DB3E; Wed, 2 Sep 2020 21:32:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Martin Duke <martin.h.duke@gmail.com>
cc: Alvaro Retana <aretana.ietf@gmail.com>, "roll\@ietf.org" <roll@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-roll-turnon-rfc8138\@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>
In-Reply-To: <CAM4esxToTtCHeMKaq5kHAJi5EZWOky4juw4PP2P2CMjm=h1ksg@mail.gmail.com>
References: <159906767077.10518.17525113825721227844@ietfa.amsl.com> <23816.1599076306@localhost> <D775F810-6962-43AC-8CB5-DDAC25E19D87@cisco.com> <CAMMESsypLvWxO4FpZcYwyeGquVwT+voJ=GOEi5xE6ZWU5SkOsw@mail.gmail.com> <14761.1599082323@localhost> <CAM4esxToTtCHeMKaq5kHAJi5EZWOky4juw4PP2P2CMjm=h1ksg@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 02 Sep 2020 21:32:41 -0400
Message-ID: <6715.1599096761@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/k8ZSA_-dZsBdCZBHcwVzzg1EB3k>
Subject: Re: [Roll] Martin Duke's Discuss on draft-ietf-roll-turnon-rfc8138-12: (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: Thu, 03 Sep 2020 01:32:50 -0000

Martin Duke <martin.h.duke@gmail.com> wrote:
    > I find this all very odd, which maybe is a sign we should simply DISCUSS in
    > the telechat. As far as I can understand:
    > - codepoints 5, 6,  and 7 are currently unassigned, though
    > draft-ietf-roll-mopex-01 (still in the WG) allocates 7 as a field extender
    > (though this is not listed as a dependency)

Right, we aren't sure what will be codepoints 5 and 6, but we suspect that we
might need them before we have an RPLv2.  Maybe.

    > - The intent of this document is to define a compression behavior of MOP 7
    > independently of the eventual outcome of roll-mopex, or indeed what the
    > extended MOP codepoints might want to do

No, that's not the goal.
The intent of this document is to define a compression behaviour for MOP 0..6 only.
We are signaling that before looking at the T flag, you need to know the MOP number.

    > - MOP 7 might indicate there is no T flag, although the current draft says
    > there would be and quick scan of draft-ietf-roll-mopex-01 doesn't reveal
    > why that might be true..

Because mopex doesn't define RPLv2.
mopex gives us enough more bits in order that we can eventually define
things.  Nodes that do not not understand the MOP value join a leaves rather
than routers (and we have several documents that clarify this behaviour).

So, the MOP value is the highest order determination of behaviour.

    > It is entirely possible I missed something critical, but as described this
    > seems unsatisfactory to me.

I think that the first step is to make get you to understand our goals,
and then you can tell us where our text led you astray.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-