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

Alvaro Retana <> Thu, 10 September 2020 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3ACD63A00C9; Thu, 10 Sep 2020 13:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AIYJ_ndlyc-o; Thu, 10 Sep 2020 13:58:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06C663A003F; Thu, 10 Sep 2020 13:58:36 -0700 (PDT)
Received: by with SMTP id l17so7734203edq.12; Thu, 10 Sep 2020 13:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=d+t5yjmUqSmoHc1K6Xseok7UBJmX+98is4r8NMHvWLU=; b=WEPXdNAF/mMFFRM0BTsA+Ss+4TWLM7FWeNkeb5hl6l29EOQPObwFQRekyLb8aiK1nP wJa1UU+7U9OKfh1QyM6g9gKdy46kbLfLK8MCzFedb9ArmSFEx6YKVY4uauTboAevWBtM 8hLE+hipxIK2plrwrvVHRNYt0xlJx6Gx4tLn7+5QJJhHpWKzkN7UkYXDO2Ma5i5bJ417 WRpcX9xBfU2FvdUvBbCemGNiuHlFklNhTzjEcXsWaVksoW/fteKh2ADJ8EYJ3svVuuhV ZkV97zHQm3zqm3sh47q0B0V3wB1wmRugc4TmHj+yzHZMOkbdHmB/zJ1nVEW61F3sY/rb nSUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=d+t5yjmUqSmoHc1K6Xseok7UBJmX+98is4r8NMHvWLU=; b=FsTFj1swuJao57yiFomzF6JtgcSc4iHgNCtUn46eBvJ1grtapOCIMAmHny5hRZfk2/ tSZu292YLyoBVo01njklso0pI4MrnCPOLkGxDosUayUEFud3kn1cf/t18zc9BT2mq+jn uVJoDbk2NUApYuoyVqFrGhtBYZv09kR9Ig+eWrrfRfg41ua4X23/b/Q+9ZTrj7v65Ir4 QOEQ+7BBsbxUIHro14ktzBc0d6SfU6QdkyOOKNthG9PrARhak4y6EDTTcRj2W49b3l9r gRNst8/gUZadMzjU0z1ky1VLAdAyZgerYpX4+zlJmocLAbZE/+a9+Hv7Ud2CP2e5pAqf 9VdQ==
X-Gm-Message-State: AOAM532hZidVmZP00/QBiGnZWIoNgODvGiemni8BSW13vCbQCoTxCTwl kveB8vayUJxA+EtYV0n9jWm+NjUGGfnEWBIUZX8=
X-Google-Smtp-Source: ABdhPJxateIY9Jq7L85DUNaAWe8+TpxQxuycrqRExtwpxoRvC8KnpN5OT7rMhBZaMIurbkcfwAI+PSbRTENadA86+Xc=
X-Received: by 2002:aa7:ca46:: with SMTP id j6mr11101561edt.155.1599771514546; Thu, 10 Sep 2020 13:58:34 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 10 Sep 2020 16:58:33 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Thu, 10 Sep 2020 16:58:33 -0400
Message-ID: <>
To: Benjamin Kaduk <>, "Pascal Thubert (pthubert)" <>
Cc: Alvaro Retana <>, The IESG <>, "" <>, "" <>, "" <>, Ines Robles <>
Content-Type: multipart/alternative; boundary="000000000000d8ad7105aefbd474"
Archived-At: <>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 20:58:39 -0000


Jumping in here on the Updates/MOP 7 point.

The only reason we’re trying to treat MOP 7 differently is because we (the
WG) know that the mopex draft is coming…which is the future document that
will define what 7 really means.

However, we’re still not there…and the mopex draft should be the one
defining all the changes.

I think the easiest thing to do at this point is to ignore mopex, and the
knowledge that things will change in the future…because we still don’t know
exactly what that future will be…this extension should then simply be
defined as other extensions have been: applicable to all MOPs.  When mopex
comes we can deal with the respective Updates, changes to the registries,


On September 10, 2020 at 4:07:54 PM, Benjamin Kaduk ( wrote:

Hi Pascal!

On Thu, Sep 10, 2020 at 12:18:48PM +0000, Pascal Thubert (pthubert) wrote:
> Hello Benjamin
> Many thanks for the depth of your review and the considerable amount of
time you must have spent on it!
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
> > We are not allocating them, but we are changing the RFC 6550 behavior
in the
> > presence of at least one of them (but are not currently claiming to
> > 6550). I have some further thoughts in the COMMENT section, but I don't
> > think the current state is consistent enough to be approved as-is.
> As Michael said on this thread.
> You'll find that we had a mention that we update RFC 6550 till -07, e.g.,
> This changed with "AD Review of draft-ietf-roll-turnon-rfc8138-07"

Ah, that would explain why I remembered seeing an "Updating RFC 6550"
section but couldn't find it in the -14!
> "
> 155 3. Updating RFC 6550
> [major] I don't think that a formal Update to rfc6550 is necessary.
> In general, a formal Update indicates (at least to me) that an rfc6550
implementation has to also support this specification. IOW, all RPL routers
will have to support the new flag to be compliant with rfc6550. Also,
rfc8138 did not formally Update rfc6550.
> "
> So on that one, I will ask you to talk to Alvaro (cc). I am still looking
for the final words on what "updates" means!
> I'm holding the publication till you and Alvaro agree on this item. For
the rest, let's see below:

With thanks to Michael for the explanation, I will quote a bit and reply
here since I am replying to the other bits, too:

% We are changing the RFC6550 behaviour in the presence of 0,1,2,3,4,5,6.
% But, we are leaving the meaning of this bit when MOP=7 UNDEFINED, to be
% defined in a future document.

Defining the behavior when the bit is set seems like fairly normal
procedures for allocating something from an IANA registry -- your
implementation knows that the flags are managed by the registry and what to
do if a bit is set that you don't support is well-specified. That applies
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. 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. So either we are changing the RFC 6550 semantics
for the DODAG Configuration Option or we are placing normative requirements
on some future document that does allocate MOP==7, and I think we have
significant experience to suggest that one RFC placing normative
requirements on future RFCs is not a reliable mechanism ... which makes me
want to go with the "updates 6550" option. Perhaps marking MOP==7 in the
registry as a placeholder with this doc as a reference could also work, but
it might make mopex a bit messier, procedurally.