Re: [Roll] Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24: (with COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Wed, 16 December 2020 10:17 UTC

Return-Path: <evyncke@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 946763A089A; Wed, 16 Dec 2020 02:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=RIZFGWvG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QEq81Kbw
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 RIrDn7Dt0s7V; Wed, 16 Dec 2020 02:17:31 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE6F3A0994; Wed, 16 Dec 2020 02:17:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13536; q=dns/txt; s=iport; t=1608113847; x=1609323447; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dxK8sUXQyUVA//SbIRJd37iWxA0afZVJSLUO7xtYPKg=; b=RIZFGWvGBo1h/WfHTny0a3iB2nE+s19nQJVa3tpxuimGEJBB99oDqOX9 9qMeNqhf1pyY4eMnaK9qmYbmnp0s68N1hInhxgK4YGMD09xhFoB63yyCK cxcUSqHs2JBJZ92hTvn3LuQzSmqkdJDOMMOoxYiSIc1BUmfZOoxqI60jF 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AYWOCdhFjw+4RMK7DPx7P1J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObVoTA4PUCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS83/fFbV5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGCQAx3tlf/4cNJK1iHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgVJRB3VbLy6EP4NIA402JQOBBYkUjnGBQoERA1QLAQEBDQEBJQg?= =?us-ascii?q?CBAEBhEoCF4FZAiU4EwIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQECARIREQw?= =?us-ascii?q?BASUSAQsEAgEIEQMBAgMCJgICAh8RFQUDCAIEAQ0FIoMEAYJVAw4gAQ6hMQK?= =?us-ascii?q?BPIhpdoEygwQBAQWBMwEDAgENQYMeDQuCEAMGgQ4qgnWCaU5Cgikbg3ImG4F?= =?us-ascii?q?BP4ERJwwQgiE1PoIbQgEBAgEBFYERAQwGAQMegxczgiyBTwkBaAdfBBgaGQY?= =?us-ascii?q?CEwx3KxUOAxcCAQ4ZBwQ8jx8SgmsBPpNXkDALJFcKgnSJI40MhRwDH4Mmiia?= =?us-ascii?q?FWYkxhWeEao8biw2Cd45RhFMCBAIEBQIOAQEFgW0jZ1oPB3AVGksBgj5QFwI?= =?us-ascii?q?NjiEMFxSDOoUUhUR0AgksAgYBCQEBAwkBe4cmASYHghcBAQ?=
X-IronPort-AV: E=Sophos;i="5.78,424,1599523200"; d="scan'208";a="843894593"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Dec 2020 10:17:26 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BGAHQRk006080 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Dec 2020 10:17:26 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 04:17:25 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 04:17:25 -0600
Received: from NAM02-CY1-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.1497.2 via Frontend Transport; Wed, 16 Dec 2020 05:17:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n+7hJRsLmPLx46xllzcXTwtanUM2cv2nxCo0PuA+vhAgpGKnpxmQsuCm37ydFfSN8DIQL44P96SWE2dZYkHVnIEp6HpIExbQ2s9YjBbpYxfsdwxKQK7a9LlBfBeeKxMeXXTjIskbH7BSoqLHiqIfZXjF+95PWrYRH94WI8eQxrvaRxhGaHjdFN+kGE2Tc/uCg1COMUiONIMIgJEwYUy3OdQHsuB065ZE6g+zi8gKmB9Os4kRks3BNShXEt8S0SIQ4KBN+3Ndype+6ZHOAOYetav62Rrlzgpaea2tE37E3aEHGvLZFJGiOBaseX+WjFBBBnSarPnA6iKWfQjn9DOgdQ==
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=dxK8sUXQyUVA//SbIRJd37iWxA0afZVJSLUO7xtYPKg=; b=QbP4sClxjgVTLIST/U0RcLDHCRmu2ScG5JnYFIsHENXLCcWiKI4WiI5y8rHKJtIKMxzI9lDoCtJo2UKRD/8yEO25wQPX+IJjgEHiF3J9Hy0db0zySV9KTtpkR1cq56ApJS4IXC+rPiZT7PbfG9wNtA5IccP+oqrIlSNrsZkEphV+8XI1E2WyBz0WYT70le6/mDVMQWcN60msDefNG9+sGbdX12VYestFaTQj6HxNtBf61Xn2fVoL12He5X5qRjNvmB5yw/e65RT04k4ahOioxUwWqX47KAtMukRhiEsQx4gBIxKH5GEBDUM61I1/8XULA+okfxG7e5T6Gi4Tu1MdBQ==
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=dxK8sUXQyUVA//SbIRJd37iWxA0afZVJSLUO7xtYPKg=; b=QEq81KbwGXbw/uFroDtcAQwTERdOcJDeKups8I6rJEl7mHUknHYb3MPDuR/KTUnUZXaFTOHj1L3jX9ynIB61+ZTZXDabU7vefN0qr5upithFbnAruDpzhD/oJksKwSdhFy07/wokl7hmIsKvn2OT9F2E1L1q4VsXm7C1PllncbQ=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5096.namprd11.prod.outlook.com (2603:10b6:510:3c::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 16 Dec 2020 10:17:24 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::4c26:8d82:d1d:e7fd]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::4c26:8d82:d1d:e7fd%6]) with mapi id 15.20.3654.026; Wed, 16 Dec 2020 10:17:24 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, JADHAV Rahul <rahul.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcm9s?= =?utf-8?Q?l-unaware-leaves-24:_(with_COMMENT)?=
Thread-Index: AQHW0vyRSigeCGrNVEaIj3VzSdnJt6n4eNqAgAEbOoA=
Date: Wed, 16 Dec 2020 10:17:23 +0000
Message-ID: <32914CE1-B508-4468-8CB5-B95501031EA7@cisco.com>
References: <160804848793.10645.17251248823923510582@ietfa.amsl.com> <CO1PR11MB488102606B20B5D33F9D5005D8C60@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488102606B20B5D33F9D5005D8C60@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:6033:6c91:6e91:b25c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2618c338-d883-4c67-6d4f-08d8a1abc809
x-ms-traffictypediagnostic: PH0PR11MB5096:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <PH0PR11MB50962F9843F4F4CBA89A6D5EA9C50@PH0PR11MB5096.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MtnEMRE5aelYuHgybjryi1bRCW7tEJIHabt7yqtrtjzFKMvJB3KBN7heM53LOAfSMAK5oYJ6AOt05T+PuoEf/mXp129/fHwKqNCR2xa0F6u/h3D8Y9TuQZ8bcDlfhj1c4U9F3Ilsa6Q7rtz9urX5uyH7QY2kB8yc4BeFFNN8QN6LuEjgKfqex2GvyF47OYtnAd6nujjyCAujuy0VSesTGkjI665v8ERYR0fplvzwFJXQu2Se/mmrnLCAuZd4GYK+ghldwoXhkQsTheJIxfPPzu4rmvVsBQ88Vqk/Mi6yiBFkaQfwc2+1CX7XkL6cLs3jzd+zI4MjDh7bpK3vB5Ds/ru/F0B2tVNkJQE0GPuoScAelfIZIWSBf8iXpTTm3zF6mXtKrJtzqss4Tq3VlPZSlEQMLGp/govrtlFiRPXTs3JaJveHADFtz/P6a34PikTCyR1ovxVOINO4gsmSgOjY3Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(376002)(136003)(39860400002)(186003)(66556008)(86362001)(54906003)(316002)(6506007)(33656002)(2616005)(36756003)(71200400001)(6512007)(2906002)(83380400001)(76116006)(5660300002)(64756008)(53546011)(66446008)(91956017)(4326008)(8936002)(66574015)(224303003)(478600001)(110136005)(66946007)(66476007)(6486002)(966005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?eStZQnBMamNROENELzVjQngvdFFRY0g0ZFF1VWVoNEk0UFc0YzFKeWlmNlRN?= =?utf-8?B?NGRwRkpoeS9UQXpPN29SRWNCNUVPT2RBeURTSVFrdEViTlFrSXdweHlWTS9a?= =?utf-8?B?TzhIcjNDZGgxd09KRXpkbDdVQzJTanlTZTZVMTZmUVZPN040QXYydmt3TGZi?= =?utf-8?B?UmZoN2dHVzBmazVxSkt5VHcrRmN3S3paU09HdDVXN1MxNjRDSjBkMzBxTkt1?= =?utf-8?B?eHNoMjhoWGNhTXpOWTRYcTlCRGd5a0lXbHl0bURtcC9uWlJjLzF5SEZTUFRl?= =?utf-8?B?SVVhb1Z0Y0NJaVc2dm94TmYrK2w2c3ljTFR0dHRLdnE2NkJWMVc5Zy84VDNQ?= =?utf-8?B?MUFIQUEwbXVQNmQ0Wm5rM1hqZHVnUlJONUVzQjNnTzU2dWV5T3B3TEdhOWcz?= =?utf-8?B?RmZ5RVlFenljTUFVbVZNTmErL0h5VTNTaTJ6VHZxMUZTR3FRcUhjdDViZncx?= =?utf-8?B?aTAvNUc3NWgxMjViNkNVa3NzT0hqNkNuUlA1eFdlcXdPbUswQnBYV3owQWVu?= =?utf-8?B?dW1BaUlTVTFXaW5BVENpOEJ0alluVC9ldWc1eG1aMmM2WDIyOUFIQ3lCT3Vy?= =?utf-8?B?OUJWWHE4YVBqUFAwc080d0wzVFhYNnFvSy90OGJVSFZEYUZNdWdpS1I2Y3oy?= =?utf-8?B?bXo3MVlXR1lia3ZPUk5kSjBFdnMwdXdrTDFscjZxRVJwZCsxRWJOemxDQkJY?= =?utf-8?B?UHBubGtMN3dBOFo2UEZmZXhsaEJJamNJZWhqbVpUVkFXc2JtVDNMSHVmQW9W?= =?utf-8?B?YVFkajlrZmpFMG1sbTBuTkFGTVdubXBCZUVpL3Q4aEJVaGlJNXk2aVVnSm51?= =?utf-8?B?OEgvUUVpWHJvamFPTVRaSFI0VFN2emtaVzdyNWx6ckRibnBORkdMZm55WStW?= =?utf-8?B?aFJyS01BeDh6eWJJdGdvLzNIMFZBMHV5NHhVWjRkbnRWOGFUa3JuZUdqUERK?= =?utf-8?B?NWN5dnV4ZTJKN3hBYlZ1WENlWk92MzBaamVLSkw1QVZiZUUyVW9WSFhtZm9H?= =?utf-8?B?NTZaOUh3R2dxQjBVV0pjbVl1dzB1T3FCcE1UMzlHbWVWRzd0MVdYQkg3VDFh?= =?utf-8?B?aTlmdUxuNXdhcVI3MXBWeXgwUU51b1J3b3lmdkNENGpVT0RiVU8wVXBzRUI5?= =?utf-8?B?eXpSV2k0NGZRKzZNT1E4dFRMN2szSkpnUlgvaStNNVlqQk9MRFhVbHY2VmNI?= =?utf-8?B?enpnM2kvejdDZDV2ZDlVd1d5d0F6V3hvOU1Xa21XSVpCRjUvenhYbUs5M2N1?= =?utf-8?B?Z25YTHh0NU04U0tlUWRRRDg4UWVBa3dHcHVNUk55Z3VnWmlseU9LdC9qVUlQ?= =?utf-8?B?b0FNbENUcG12V0NjT0VKT0dVdWpSd3FWKzVjVDhNOFlGVlFkZ3lUWWZTNHNz?= =?utf-8?B?eGM5ZzJhWUxqSUlRVWlINzI3S0RaQjlhdTR1NzJ4eTZqek40c2dnSno3VXh1?= =?utf-8?Q?S+VcxGFH?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <D353CDABE212C94094CB79D22D649D33@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2618c338-d883-4c67-6d4f-08d8a1abc809
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 10:17:23.9450 (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: POdqivcyP2L13Y70tqDz3/jCpAxmPziWNxKIn/JWRxI7L2zYDGnOK4Q/Uuz/q+DreC3MMgjrwlQ7aLExGH/wCQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5096
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/A2PE4VSN6iPjuf7vGYC88FXS_fQ>
Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-roll-unaware-leaves-24=3A_=28with_COMMENT=29?=
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: Wed, 16 Dec 2020 10:17:34 -0000

Bonjour Pascal,

Thank you for the prompt reply as usual. Nice ASCII art __ and sad that SRH was already used in RPL foundation RFC. Thank you for the explanation about ROVR length field but as with the ND status transport in RPL status; as I do not have alternative proposals, I won't object but still find these techniques smart and ugly at the same time.

I still think that the abstract is not very useful for the casual reader in the current form.

Else, thank you for all the changes

Thanks as usual for your prompt reply and enjoy well-deserved vacations as well !

A+

-éric

-----Original Message-----
From: Pascal Thubert <pthubert@cisco.com>
Date: Tuesday, 15 December 2020 at 19:24
To: Eric Vyncke <evyncke@cisco.com>om>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>rg>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>rg>, "roll@ietf.org" <roll@ietf.org>rg>, JADHAV Rahul <rahul.ietf@gmail.com>om>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>om>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24: (with COMMENT)

    Hello Eric

    Many thanks for your review! Always appreciated as you well know.

    I pushed the result here: https://github.com/roll-wg/roll-unaware-leaves/commit/b5cc06f224389d1a436dbb4468cb7f07a6307b17

    You'll find the diffs combined with Elwyn's review here:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-25


    Please see below for the details:

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document. While the authors spent a lot
    > of time in detailed explanations, I found this document hard to read, perhaps
    > some additional diagrams may have helped (like those in section 9).

    Added this in the intro, sorry if it does not show well in email with your default font

             ------+---------
                   |          Internet
                   |
                +-----+
                |     | <------------- 6LBR / RPL Root
                +-----+                     ^
                   |                        |
             o    o   o  o                  | RPL
         o o   o  o   o  o     o    o       |
        o  o o  o o    o   o  o   o  o      |  +
        o   o      o     o   o   o    o     |
       o  o   o  o   o  o    o    o  o      | 6LoWPAN ND
          o  o  o  o        o   o           |
         o       o            o    o        v
       o      o     o <------------- 6LR / RPL Border Router
                                            ^
                                            | 6LoWPAN ND only
                                            v
                    u <------------- 6LN / RPL-Unaware Leaf

    > 
    > Big thanks to Peter Van der Stock for his Last Call review at:
    > https://datatracker.ietf.org/doc/review-ietf-roll-unaware-leaves-23-iotdir-lc-
    > van-der-stok-2020-12-08/
    > Peter completed his review at the same time as -23 was published, so,
    > authors, please have a look.
    > 
    > I appreciate that the shepherd and RTG AD have contacted the 6LO WG for
    > review (even if no comments were received).
    > 
    > Please find below some non-blocking COMMENT points (but replies would be
    > appreciated), and some nits.
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > 
    > Be aware of a down-ref: Normative reference to an Informational RFC: RFC
    > 7102

    Yes, Elwyn also mentioned it. There's an action in Alvaro's side to allow the DOWNREF exception


    > 
    > -- Abstract --
    > Suggest to expand some acronyms in the abstract: RPL, ND. In the same vein,
    > writing that RFC 6550 is RPL could help the reading of the abstract.

    RPL is awful to spell spell out. I changed the abstract to
    "
       This specification updates RFC6550, RFC6775, and RFC8505, to provide
       routing services to IPv6 Nodes that implement RFC6775, RFC8505, and
       their extensions therein, but do not support RFC6550.
    "


    > 
    > -- Section 1 --
    > s\whereas others will only terminate packets\whereas others will only
    > receive/originate packets\ ?

    Done

    > -- Section 3 --
    > "packets going down" could probably be rewritten in a more formal way.

    Actually that's a RPL term defined in RFC 6550.
    Changed the terminology section to 
    "
       "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
       a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
       Protocol for Low-Power and Lossy Networks" [RFC6550].
    "

    > 
    > The use of "Source Routing Header (SRH)" is commonly linked to RFC 8754
    > Segment Routing Header... May I suggest to use 'RH' (as the "source" is always
    > implicit in RH).

    Yes, it's a sad collision, but it's quite late. We also use the acronym in the RPL space. 
    See RFC 6554 and RFC 8138. We should ask for Royalties ; )
    I hope that with the context people will expect we're not using a SR RH here.

    > 
    > -- Section 6 --
    > Does the "reserved" word have any value in "encodes it in one of these
    > reserved flags of the RPL DODAG" ? With the publication of this document, it
    > is no more reserved IMHO.

    The sentence was weird; I changed to 
    "
       This specification defines a new flag, "Root Proxies EDAR/EDAC" (P), in the
       RPL DODAG Configuration option ..
    "

    > 
    > -- Section 6.1 --
    > Should the normative uppercase language be used ? E.g., "length of the Target
    > Prefix field is 128 bits regardless of the value" is not really normative...
    True, changed to:
    "
       This specification defines the new 'F' flag. When it is set to 1, the size of
       the Target Prefix field MUST be 128 bits and it MUST contain an IPv6 address
       of the advertising node taken from the advertised Prefix. In that case, the
       Target Prefix field carries two distinct pieces of information: a route that
       can be a Host route or a Prefix route depending on the Prefix Length, and an
       IPv6 address that can be used to reach the advertising node and validate the
       route.
    "


    > 
    > I also wonder in which case the ROVR length cannot be derived from the
    > Option Length and the Prefix Length (the HbH option length is expressed in
    > octets per RFC 8200). Wasting valuable flags space for a length seems a bold
    > decision to me. The text describing the option is convoluted so I am not sure
    > about my point else I would have balloted a DISCUSS.

    The problem is in the future, when we want to extend the option with yet another field. 
    If we did not indicate the size of the ROVR, then where does it end and the new field start?
    We faced that issue in the EDAR message, had to steal even more expensive bits. See https://tools.ietf.org/html/rfc8505#section-4.2



    > -- Section 6.3 --
    > While I appreciate that there are severe constraints and while I admire the
    > authors' imagination, the mix of status codes looks like a chimera to me.
    > Nothing blocking, just a comment of mine, no need to reply.

    It's really transporting the ND status in RPL so it can be fed back in ND.
    My original intent was that RPL would be ND for NBMA, when broadcast  emulation like MARS is too expensive.


    > -- Section 9.1 --
    > Is there a reason why "Extended DAR" and "EDAR" coexist in figure 6 ?

    Because there was room : ) I did not expect a confusion. Changed all to the short form.


    > 
    > Not the first time that "aligned" is used, e.g., in "This flow requires that the
    > lifetimes and sequence counters in 6LoWPAN ND and RPL are aligned." but is
    > this term well defined and well accepted?

    Argl. No idea. I hope I'll get a recommendation from a native speaker. Elwyn made great comments and did not object here.


    > 
    > What is the meaning of "negative" in "an NA message with a negative status "
    > ?
    > Most significant bit to 1 ?

    Argl. In RFC6550 you're actually correct but here it's ND and arguably it was not defined that way and I'd rather not do it now. Changed to "non-zero status". Which are strictly positive values but indicate failures which is a negative outcome. Also changed one occurrence of "positive status" to "status indicating success"
    > 
    > -- Section 11 --
    > Should a rate limit of EDAR/DAO message by the 6LR be recommended ? RFC
    > 4941 could be our enemy here...

    This is RFC 8505 at work.  It lists some security protections but I've not seen that it is explicit in that regard. 
    RFC 6550 has it in section 18.2.6.

       An implementation should support rate-limiting the sending of DAO
       messages.
    "

    > 
    > == NITS ==
    > 
    > Unsure whether capitalized "Host" and "Router" and "Leaf" are required.

    Uncapitalized, but in the form RPL-Unaware Leaf that I left capitalized

    > 
    > The companion document uses "IPv6-in-IPv6" rather than "IP-in-IP"

    Changed

    > -- Section 5.3 --
    > Please expand HbH in the section title.

    Done

    > -- Section 5.4 --
    > Suggest to drop " and the packet is dropped otherwise."

    Done

    A great many thanks Eric!

    Please let me know if I need to do more.

    Take care and enjoy well-deserved vacations : )

    Pascal