Re: [Roll] comments on mopex-cap-00

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 26 August 2019 09:32 UTC

Return-Path: <pthubert@cisco.com>
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 80651120125 for <roll@ietfa.amsl.com>; Mon, 26 Aug 2019 02:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=be9Lri9y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sSl6J7LS
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 JAOB9FYOtvMQ for <roll@ietfa.amsl.com>; Mon, 26 Aug 2019 02:32:09 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE92120826 for <roll@ietf.org>; Mon, 26 Aug 2019 02:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5283; q=dns/txt; s=iport; t=1566811928; x=1568021528; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qgVCmCmyc+L65srdS/hA0d0e+XyBON0EC/m5/P3+RNU=; b=be9Lri9y9SbFPROxXGU9mVz8t1432MjEFGVe4ZRtN4kwI43GmEUohPi1 Bc4hRSELE55kMxtsrK5yYYOatCz7IjclXI94AunDYxHs5mY0e/3SI4zh7 j183plc69ED9GEKGvVFa36ncEq4NvhGtU/BBwBxp9GkB2rBBVGp0UFpha o=;
IronPort-PHdr: 9a23:c8p7ih0+gekPIfiEsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALCgDJpWNd/5tdJa1kHQEBBQEHBQGBZ4FFUANtViAECyqHaAOKbE2CD5doglIDVAkBAQEMAQEYCwoCAQGEPwKCZyM4EwIKAQEEAQEBAgEGBG2FLQyFSgEBAQQBARAuAQEsDAsEAgEIEQQBAS8nCx0IAgQTCBqDAYFqAx0BAgycIQKBOIhhgiWCewEBBYR+GIIWAwaBNIR9hnUYgUA/gRFGgkw+gmEBAYFFHoM7giaVMJY+CQKCHoZqjXSCMocwhBuKUo8ehjWQOwIEAgQFAg4BAQWBZyGBWHAVO4JsgkKDcoUUhT9ygSmOBgEB
X-IronPort-AV: E=Sophos;i="5.64,431,1559520000"; d="scan'208";a="314485588"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 09:32:08 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7Q9W7I2010578 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 26 Aug 2019 09:32:08 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 04:32:07 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 05:32:06 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 05:32:05 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EBrcARWuM35eXW5VYeBaKyJBa9qsU1SsNGXSKoCirCw2yxpABMOBxX/1NWNaUCaMhdTyuQysdpVhJ+ShXr64S8em+qIBQY4VXkziEUqo7fXtqZ8TjexoIfIWvn64N/ezHxNEZAlttluT0rbzE5EREw8CWA8EoAFxoSKZosk4lrknIyX7m949LaTPPcmH8YUNe9JPbv7J5B0nRnBsE07CbXG0SRGHpm/r8BLDne9IWBtNdrTwQAerPvrgGGA+yVXaAstK1diJUWG0nMGQ2nU2dbqaE/8BUoU/XnULHeCEZVoVJbM4BMZxpgqNkw7XKZj03v+S7HJkOsWsWQXKRHvMjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g/LaBXtkDoN7c1xV4i9O7N68wpyd7KNwHBkTNxXrRYQ=; b=WKRyrOlZQwHGB/UPjpF+P3bDGkrCr7F/LBKrGavOi02twfKAW3Hj5wkqcmWPuwwiGE1JWBbQLwKLERN5GcN0+cC5rcPBn5zDrwrWYcKtBIs1VtICsNYqbx3od0Dq6b7Ivme5SvUbBYGInpiGvytqbILYWQLxSGWGcl1squOeRZupL8nxQKBXe75EspSSy1n4yBvgx7uW7HMTDvV0hWWalIp9hyLWMZBHBEeFx3FTDdTsSKGVZ/BAp15Ymp0TYFXEiNuzpzEHI04s9vvo6xlu3W3el8VfT0ri8VV3ntebkpVALCjI6jyZj4l9OnCqgPquy9g/BlpkShJky/RzflzP4A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g/LaBXtkDoN7c1xV4i9O7N68wpyd7KNwHBkTNxXrRYQ=; b=sSl6J7LS65xKuTGD0lXx5B5CUq7yR+n4y1khrwa8J17JYV67ZEAUti9PWPmAP5am4bgLxk3r9LmIsUBXzlDC1U8VuRU9VrHTkkXGpMT8gStoAACQX8BmIztaOKRoJKqfPrR/2FnOAo+AIZJuXgitepiHfVeJs6/BnlYhB5RwgbE=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3759.namprd11.prod.outlook.com (20.178.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Mon, 26 Aug 2019 09:32:04 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 09:32:04 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] comments on mopex-cap-00
Thread-Index: AQHVWfP0dJKtxPToUUalM4PDxdaoiKcLtrQAgAF1wcA=
Date: Mon, 26 Aug 2019 09:31:45 +0000
Deferred-Delivery: Mon, 26 Aug 2019 09:31:24 +0000
Message-ID: <MN2PR11MB35653CC9F9761C45A4963701D8A10@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com>
In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1003::f7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 379ce1c6-024a-4cd8-4210-08d72a0841d9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3759;
x-ms-traffictypediagnostic: MN2PR11MB3759:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MN2PR11MB3759AF513CFC761A85FCBB84D8A10@MN2PR11MB3759.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(366004)(13464003)(51444003)(199004)(189003)(6116002)(966005)(6436002)(6306002)(55016002)(53936002)(9686003)(25786009)(33656002)(86362001)(6246003)(5660300002)(66946007)(71190400001)(71200400001)(102836004)(99286004)(76176011)(7736002)(53546011)(6506007)(305945005)(74316002)(229853002)(486006)(11346002)(476003)(446003)(2906002)(316002)(52536014)(8676002)(6666004)(186003)(14454004)(66446008)(64756008)(66556008)(66476007)(256004)(478600001)(14444005)(6916009)(46003)(81166006)(8936002)(81156014)(76116006)(7696005)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3759; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lVsA3PUXbHxD4Z4aJVQKxNMMALXq9+v0Ozdg0pEZQME+kXMKNIw6a66e7PlYWDQpIS96hhUZx1S/wAUo61TyIdJwB6anMLCLGj+nScLgWAAEyfR0rbotzKok3dlZdVGeBoR6lquDTcuh8JcKSsG9ydiTALmrtntzJJltJwPpMGZEm3uV+RQhZ/3dH2Hc99wc3wPQYPLAVJ9o44TkPTHvbdCrH+OsdMeqSDCntvVKUEIPYsbEmJRxSYEeGStaFCtuvE1hVv3EwyC41rDyR9G6VYlzYXjDmWQl8iHC6rly5kmEF+X2myU+dN0a1oum2/2Jk1QPmw32oa9iJkhU2fwH/KO0wAVhe5zudKlU8V6sz7fFnF8BebRqIw2oTtIkS78vDD6D7jI8KS5fzD2IMujDL76U/QOtVn3iV0PqUjxh010=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 379ce1c6-024a-4cd8-4210-08d72a0841d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 09:32:04.7527 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gqUPgUkwcv3nVAxQ6+NsDbNSWG5DtiRb8bjQQPLaywndmY4wHLWsa2dXXD06GdM99rly7O7jQoc5eK7ilTm+5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3759
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Dchf3M613iopxUO547NLS6o5Q-0>
Subject: Re: [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: Mon, 26 Aug 2019 09:32:12 -0000

Hello Michael

There were headwinds against flooding the IESG with too many small documents. Now, we ma be wrong in this case and I'm perfectly OK to split if the ADs recommend to do so.
In this case, we have 2 functions which, though logically separate, are both needed infrastructure. This gives us an infrastructure uplift spec and a single reference for all the work that will build on it. 
As Rahul says some new components will need a bit of both at the same time. So keeping together is defensible.

All the best,

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Arvind Jadhav
> Sent: dimanche 25 août 2019 13:08
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] comments on mopex-cap-00
> 
> Thanks Michael for the review and feedback.
> 
> Please find my comments inline.
> 
> 
> 1) If Capabilities and MOD-Extension are mutually independent, why is it in
> one document?
> [RJ] I raised the possibility of keeping it in separate document in IETF 104. But
> no one voiced any specific reason to separate it out. Even though semantically
> the Capabilities and MOP-Extns are mutually independent, some of the
> scenarios discussions might require to discuss them together. Do you believe
> we should separate it out and if there is any advantage doing so?
> 
> 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?
> 
> [RJ]: MOP is indicated by the root and the whole network has to follow it. The
> capabilities on the other hand are node specific. For e.g., the end node can
> indicate that it supports a primitive via cap flag and this info could be used by
> the root and vice-versa.
> The answer to your questions above is, "Both".
> 
> Are they individualized, or does every node in the
>    LLN have to support a capability before it can be used?
> [RJ]: Nice point. I haven't thought about this in detail. In non-storing MOP, it
> may not be required that all the nodes support capabilities but in storing
> MOP, every 6LR needs to add the cap (if present) of the downstream child,
> thus requiring every node to support it. This definitely needs handling in the
> draft.
> [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/1]
> 
> 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.
> [RJ]: I am ok with this approach. Will update the document.
> [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/2]
> 
> 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?
> [RJ] With point 3 accepted, this point is not relevant anymore. (?)
> 
> 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?
> [RJ] I meant that caps and MOPex do not depend on each other and are
> mutually independent. May be I should :s/exclusive/independent/
> 
> 4.1: >There are no capability flags defined by this document.
> 
> that makes it really hard to know how they work :-) [RJ] Yeah, should have
> added an example. Will be done in the next update.
> [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/3]
> 
> 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.
> [RJ] Actually I am not sure that this will be true going forward. Why can't a
> intermediate 6LR add its own capability in DIO (without depending on root)
> for its downstream childs? If this is the case then the draft's above statement
> is not true. I am glad you pointed this out and wish to discuss more on this.
> 
> 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.
> [RJ] I am considering this for the example use-case of caps
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll