[Roll] comments on mopex-cap-00

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 23 August 2019 20:46 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A2972120119 for <roll@ietfa.amsl.com>; Fri, 23 Aug 2019 13:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fYe0Loaujeyp for <roll@ietfa.amsl.com>; Fri, 23 Aug 2019 13:46:50 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F921201CE for <roll@ietf.org>; Fri, 23 Aug 2019 13:46:50 -0700 (PDT)
Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com []) by relay.sandelman.ca (Postfix) with ESMTPS id E9CC61F45E for <roll@ietf.org>; Fri, 23 Aug 2019 20:46:48 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9C6463FB5; Fri, 23 Aug 2019 16:47:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 23 Aug 2019 16:47:18 -0400
Message-ID: <14914.1566593238@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/ePo9u9Y8RgBkGaja3oau4N_5OSU>
Subject: [Roll] comments on mopex-cap-00
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: Fri, 23 Aug 2019 20:46:53 -0000

1) If Capabilities and MOD-Extension are mutually independent, why is it in one document?

2) MOP clearly applies to the entire DODAG.
   I don't know if Capabilities do from the description:

   REQ3:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.

   Are they things that the root tells nodes, or things that the node
   tells the root?  Are they individualized, or does every node in the
   LLN have to support a capability before it can be used?

3) I argued before against the Extended-MOP-value being added to the Base
   MOP. I prefer that the value 7 means *replace* the MOP with the MOPex.
   Yes, that results in two ways to encode MOP="3", but I think that it
   leads to far less confusing code.

4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean?
   (Nothing, I think it should be ignored)
   Would we really ever assign a new the value 7?

5) section 4.0:

>   Note that capabilities and MOPex are mutually exclusive and it is
>   possible for an implementation to support either or both of the
>   options.

I think that you mean, not mutually exclusive?

4.1: >There are no capability flags defined by this document.

that makes it really hard to know how they work :-)

4.2: use of "could" is very non-normative.

>   Capabilities
>   advertised by non-root nodes are strictly a subset of the
>   capabilities advertised by the root.

This should be in REQ3.

7.1/7.3. If you take my advance about not adding, but replacing, then this
document would Update the Mode of Operation registry, and we would not need
a new registry.

==== having done all of this.

How will DAO-projection signal itself?  It seems like a capability to me.
I haven't read that document in a few months.  If it uses capability, then
this document that creates capabilities SHOULD probably allocate a bit in
it's initial table.

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