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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 16 December 2020 11:08 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 AA2D03A0981; Wed, 16 Dec 2020 03:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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=jmH1r0Sb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wULXX0Uz
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 34VAZ_e-6WHr; Wed, 16 Dec 2020 03:08:39 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547133A0978; Wed, 16 Dec 2020 03:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15486; q=dns/txt; s=iport; t=1608116919; x=1609326519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pnKKLku+vGejv6iprQxSJTxtpJ8z2n3M5X0o5IGBu0Y=; b=jmH1r0SbQUOaLnb3JNimeZ0ueTNMk0l/sNJqPh6D8wITn2+Iy5FEWDxI yeZAOgCCuot/78TiMj2hzCyLZ2JUA53GQHop2kXBKo5fBjubmNDqJeWAC IpGtQVMQIGjMYuMCND3uJWXn3N092a6zbDuT5m4KHNWUpyU3RYQuMJuUJ Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3Am/QnvxYK+11SIwurFSidWBH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD47a8PlDzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX1ZkbZpTu56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzBgCu6dlf/5hdJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUiMuB3VbLy6EP4NIA41bA4EFiRSOcYFCgREDVAsBAQE?= =?us-ascii?q?NAQElCAIEAQGESgIXgVkCJTgTAgMBAQsBAQUBAQECAQYEcYVhDIVyAQEBBBI?= =?us-ascii?q?REQwBASUSAQsEAgEIEQMBAQEDAiYCAgIfERUFAwgCBAENBQgagwWCVQMuAQ6?= =?us-ascii?q?hRQKBPIhpdoEygwQBAQWBNwIBDUGDFw0LghADBoEOKoJ1gmpOQoIpG4NyJhu?= =?us-ascii?q?BQT+BEUOBWEk1PoIbQgEBAgEBFYERAQwGAQMggxUzgiyBTwkBaAdfBBgaGQY?= =?us-ascii?q?CEwx3KxUOAxcCAQ4ZBwQ8jx8SgmsBPqQHCyRXCoJ0iSONDIU+gyaKJoVZiTG?= =?us-ascii?q?FZ4RqjxuLDYJ3jlGEUwIEAgQFAg4BAQWBbSNncHAVGoMKUBcCDY4hDBcUgzq?= =?us-ascii?q?FFIVEdAI1AgYBCQEBAwkBe4cAASYHghcBAQ?=
X-IronPort-AV: E=Sophos;i="5.78,424,1599523200"; d="scan'208";a="831588836"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Dec 2020 11:08:37 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BGB8aZW021008 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Dec 2020 11:08:36 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 05:08:36 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 05:08:35 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 16 Dec 2020 05:08:35 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oqnk7648ur39BGgibel5W8mg26qFjop3oIKB3mmsppMjGntR9v+8yRVGSqyteJYQn080dnMEXLSvRj6bTBdvI/3jiPBY8uUPFzg1rZBcC5mHygP7oyWOBi7zZXy6AQErKlxzFTYaXbRd7irqjK6eLRX633lj7Gmq4F373tfCab50LAumkFJLv1a43LhoZ5nj5gVi41bJyMyY/kcuZu6PwtP56XiT7mfZobDMAM+VethwAeAJo+6QkGoOo67D9/1dsOt5beTD3/lFy52G86yQRVCTNCElMpoS9hDCVCntOwoJsX7Ck/6co3q8OE05/2lcnY72C8a5YkdKEcnQ6mQISw==
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=pnKKLku+vGejv6iprQxSJTxtpJ8z2n3M5X0o5IGBu0Y=; b=ZMS3B1RrnQgEz2Ge9xS23zggIuin/kaOx+/OM3T5QN9Y4ENvXUPeq8rqFEE79jUjNRwxY26JwiC+tWL8KtgXdoKoPdqwn5sMUyIO8zCUWReRZK3NgrdRjDYYhSwuwVqhG8hFyd/7eW8k5IWIjhgyeFAh5fM3ldKj5rErn8dnx4Czeaxm8rvYziEQ7tCWp7Za1dQ+LDNdQquUYOENjLuzZw1Jyl46n9CZBZQfhtmXoAsfZycjOlR6SGJR2Hsp6vkuZklxEVbr84L3L45eK0VuN6V64QzQtUY/gh1O/O7ocB2qPRVfZyclk2V/kg87AwFIuCWz1RbqWNsayAEGXvKtTg==
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=pnKKLku+vGejv6iprQxSJTxtpJ8z2n3M5X0o5IGBu0Y=; b=wULXX0UzLOUjDBbfWdzF2TTE1XduStpVPMFQpM6RF9+XUj7rQuBHqGH5CR+C5NhyQXXXTuAQbULIA7xcekfTUSfeHYIhvf/Jp/t6wZf+5sZT4ZtB2r6i1W63WIdF4aybxbDsE+RYIY7dD5CeRGC+FQgD7AURwfMLjsBpPsamcZg=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4652.namprd11.prod.outlook.com (2603:10b6:303:5a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.18; Wed, 16 Dec 2020 11:08:34 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::499:4510:59d6:8f61]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::499:4510:59d6:8f61%4]) with mapi id 15.20.3654.020; Wed, 16 Dec 2020 11:08:34 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@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: AQHW0vyJNgiFu7yP40iS2SITa/FBUqn4YA/AgAEjQYCAAA2eIA==
Date: Wed, 16 Dec 2020 11:08:13 +0000
Deferred-Delivery: Wed, 16 Dec 2020 11:07:37 +0000
Message-ID: <CO1PR11MB488170AD090D3D034595B8EED8C50@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <160804848793.10645.17251248823923510582@ietfa.amsl.com> <CO1PR11MB488102606B20B5D33F9D5005D8C60@CO1PR11MB4881.namprd11.prod.outlook.com> <32914CE1-B508-4468-8CB5-B95501031EA7@cisco.com>
In-Reply-To: <32914CE1-B508-4468-8CB5-B95501031EA7@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: [2a01:cb1d:4ec:2200:80f0:4acd:dde0:b36f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 39ab3260-096f-4175-daa5-08d8a1b2ee2a
x-ms-traffictypediagnostic: MW3PR11MB4652:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW3PR11MB4652765534488B194423BECCD8C50@MW3PR11MB4652.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: a585I2BC/xoZPxaKeHXWDp5FjYuA0QYZsJ/RBlXMz/dMk+VTE49VjbsS9bXawGqoH/wL1hrqgocy+95H2ozh9IuK8jwsHhkWHA+3dgD8BnLf+ilxjNRqtUKY9qMIVr2qOOAKS6W20083Yn716V7KK6fDXDmnBvaku7teCRaD1tYHB1aHZ/M2x6AGAb+YNPOGtdtbwY53YIwcssxJHV42BU1K89I8mdYcvJJnHlajwDe7/ifY+97sJTU7bEKIqDHw3uZu+6L1K1D9HicNv2LHgSZjzQLbYViyGZ4GqObINPvgKiMx5WkTGd8kqJRAsfS+aOuMH9gn0T4fycUwB/4N+Zcl/vSINlIOwS9FCBx+1Gf7SnZRS+YDojHk0gb9TSQduSfEZcgAwzi2EyiQ35O8iw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(376002)(136003)(396003)(346002)(966005)(83380400001)(76116006)(224303003)(478600001)(66574015)(7696005)(52536014)(66946007)(55016002)(66476007)(6506007)(71200400001)(54906003)(66446008)(66556008)(9686003)(33656002)(2906002)(316002)(64756008)(5660300002)(110136005)(4326008)(6666004)(8936002)(53546011)(186003)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?SUJJYU1tdWsxcDFNM0lWSzh3SjB0UmN5QmVvOTU0a2xRT3NmVTY2d09mRXF6?= =?utf-8?B?STVEUDc5eUdZSjdUdE1iVmhyeEpLR2hJbDN0N1NabkJyVG9aV2h1ZjFnb1NP?= =?utf-8?B?ZS9paTNyVndFaFg3eE5RNi9QdCtMMldkM2xTUzNJTWg5MEhzbCtGbEhTeGhZ?= =?utf-8?B?azdjMDhjN3AyUU5rRWkvcTlKSHk1dTM5U3ZGQmdWZHkwUXgveEtyVXNFZ2d5?= =?utf-8?B?WFNrRzc1N0dNY05yZVBBanVNUTVGaS94VjBtQjRUdG1jRTlIOUw5cTNoNjl4?= =?utf-8?B?ajJ5VWFTekZVNUNYSkR0akRDVE54KzhjWVhpTTRBSmVXTWVlTzJ2TExDRGsv?= =?utf-8?B?d0ViMkdHMHU5U25TUzlkY3g4ZEs3YTdJTm9rRUpKT1JyN0docnA4TCtzWEUz?= =?utf-8?B?V29TNTI5QVg5a0FseGFQNGJ1RDFseDdIelVrS0ZXdjdPVlNUdUMrWjNuWUhT?= =?utf-8?B?SDdGa0VpM0FlaWNaL3NubkNOaEZoS29uZ2JKMFhSUlc5RmFTaXlHZU9CRXRm?= =?utf-8?B?dDhkSHlJZ2xkWmdGMVNON252NTE1OHJiMVJWVkw2WmM1UWpTdjI3M0pONXhS?= =?utf-8?B?Tm9wUEQ1d0loUTRJL3VRQnJKLzJZS2MxSUtUaGdDRFAwdjhMWUZUM2lkaXBt?= =?utf-8?B?Uy9zTWVnOEIxRUFXd2hGeE0reWF3VTllUnBaS3doRk84VHBXeXdsUmNjVjlz?= =?utf-8?B?aDJtTFZjdVVacG5YQ0l6ODJ6NTdxVG1SbHZjMGMxbzdGdXVwT082amhMQ1FQ?= =?utf-8?B?WTRIYWNpMU5ScmR3cVdHWTFVQU9rVmh6M21WTFluZTlzY1VOSTIyMm1rbmx0?= =?utf-8?B?VEdTTmRDanZ6REZkWjhVMSs1TnF0UDJ6MEhKeGEwZ0lZdFZxeVBWQzRCZ29w?= =?utf-8?B?VjlNT1Vsc3ExZ0ZkeUJaQlgzVjl0MkZtMlU5RHhQVnl6RklBQ2llWFEzZC9B?= =?utf-8?B?RVk2QnNPMW5SSXlzSnFzakFwVUFyQkNjR2xZemRWNFdFdVhkOWR0cXl4U0Z4?= =?utf-8?B?d0J6RVdYNnp0RmVMTStTR09QdUp0UWYzazJFbDhXYisrQzFsUUtLbExtZ2Rw?= =?utf-8?B?Rjc2VFRrc1FmaWJIOVNsdDVhTmtHSlBzSnFWR0Z4QmppOWFITDFHWXgyUlF3?= =?utf-8?B?MXRCenl6aW94TkI3eW1RL2FrZUluMDZFRDI5dGljUWx4Q2RQYThSemczZ2tG?= =?utf-8?B?bnVVb3Y5VnZyNThtQXJZbzVMdjRhdTh2VVE3bnlEMGV5UVZSNyttY1UrNUNi?= =?utf-8?B?YW1zSlNaemQ1RlhXWVNrSXBhRlo1eEw1Vi8vT1AwVno2WkdYVmxsTGlJZUVm?= =?utf-8?B?dzZ6T2dFZEgzOUNieGptU1hGK054bk9OY0orTnJaV3hGb3F6SGlDZDR6SUpP?= =?utf-8?B?akYxaUM1NE1CaWthSDlGd1U1a29NOFA2bnB6dVJyUVlmaSt1Vkc4Y3IvUVdu?= =?utf-8?Q?a18ZS2t6?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 39ab3260-096f-4175-daa5-08d8a1b2ee2a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 11:08:34.4254 (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: gVTK9uhy/K3ZqSjlUdS1YIF39sVMLnJkD4aiL93Tw6QHO1yIPwJo3nm0pV9LqCgeDxYKtTPRKcuP30GhnYDebw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4652
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mZXehTDE-omWv-XPo4R4n8wNzNU>
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 11:08:44 -0000

Hello Eric:

For the abstract, would "
  This specification updates RFC6550, RFC6775, and RFC8505. It provides a
  mechanism for a host that implements a routing-agnostic interface based
  on 6LoWPAN Neighbor Discovery to obtain reachability services across a
  network that leverages RFC6550 for its routing operations.
"
Be better?

Take care,

Pascal
> -----Original Message-----
> From: Eric Vyncke (evyncke) <evyncke@cisco.com>
> Sent: mercredi 16 décembre 2020 11:17
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-roll-unaware-leaves@ietf.org; roll-chairs@ietf.org; roll@ietf.org;
> JADHAV Rahul <rahul.ietf@gmail.com>om>; aretana.ietf@gmail.com;
> consultancy@vanderstok.org
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24:
> (with COMMENT)
> 
> 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>gt;, "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
>