Re: [Roll] RtgDir Review: draft-ietf-roll-unaware-leaves-23

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 22 January 2021 12:46 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 7FEBE3A0B33; Fri, 22 Jan 2021 04:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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_H2=-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=fgURXDiJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=svZ6YBdR
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 6CWt_x7xPRCD; Fri, 22 Jan 2021 04:46:32 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8467A3A1282; Fri, 22 Jan 2021 04:46:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18306; q=dns/txt; s=iport; t=1611319592; x=1612529192; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1I6IJq1llxyLz6xA3Y4uEAAoP7nN1eUIGID5OmAJZRY=; b=fgURXDiJ+rqELYABWY6ezjQI40A+B8TKrU8zk9Rxv4QRRu4sL4FuRMUU x1uZj29t95FHBhotD0ZX8iROC1AsIlU2vjz+PjwE4AQaA7SYE/3V6Okfc zSNRqMINAyJs2Se+NV4XMG5Z1LtMZyqKvxpUbEaAOcs0NQeW1LYmnInhy A=;
X-IPAS-Result: =?us-ascii?q?A0AtBQDNxQpgkI9dJa1iHgEBCxIMQIMiUX1bLy+EQINIA?= =?us-ascii?q?44OA4EFjgyKBoFCgREDVAsBAQENAQEjCgIEAQGESgIXgWECJTgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgQUAQEBAQEBhjgBC4VzAQEBBA4VEQwBASMGCQUBCwQCA?= =?us-ascii?q?QYCEQQBAQECAiYCAgIwFQgIAgQOBQiDHgGCVQMuAQ6WeZBrAooldoEygwUBA?= =?us-ascii?q?QaBNwKDZxiCEQMGgQ4qgnaEA4JOg3QmG4FBP4ERQ4IhNT6CXQEBAgEWgSwcF?= =?us-ascii?q?YMCNIIsgU8KaQYBYwQUDg0DEQgGAhQOURITCCkCEQEFASAOAWCPTIMsh2CME?= =?us-ascii?q?ZA3gQgKgneJMJJdgyuKM4VjiUOFcJMrc4IHhx2BepFyhEMCBAIEBQIOAQEGg?= =?us-ascii?q?W0hgVlwFRqDClAXAg2OIQwOCYNOhRSFRHQ3AgYBCQEBAwl8iwoBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AMQMqGxS9fw5xRjrEFtmuGjoNLtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ7OhNjeXb9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7VuHS04jNUER?= =?us-ascii?q?L6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.79,366,1602547200"; d="scan'208";a="672562156"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2021 12:46:31 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 10MCkVnq007117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2021 12:46:31 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 22 Jan 2021 06:46:30 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 22 Jan 2021 06:46:30 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 22 Jan 2021 07:46:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M3UPHvmDZgYrzLdDyavu3H5jsO5lWeB9lXUXFSK9aFoKyEKuM205yaKy59tjotwOrBvXEG6PGVF2Lra7uUHwa6N4hCbVwa7deSZOKiEpMzesRxisNPtR+MsvKLnvZzIrPA/IFS7YFbNTIiqJeHNt2g2zmxP8pfB8K8d6ZqSiYfvr1VrRUoPzRWs2KdWwxNxXmMgtGzpCInUnF/WpUeTNZjoF5tINdYS+QVfvRB+GV1cLsVLjPFHyWIj7szwSTW48AebNRXMtUk/i2B7RitXHRbevxjyEMw4PqpQXVAQKRU/NkF1vkDsXolABvWKv0+HYH+dTzDqi5PEHEAdTfU8TKA==
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=1I6IJq1llxyLz6xA3Y4uEAAoP7nN1eUIGID5OmAJZRY=; b=W/v7VGLe+t3T5AvIb8qx5TlJuvy7ZFcbTb2VJoj0FN+vFbGucbDg1Ez9S8v5WaW5jIq4I3s4JV3EcEQ/MZuZ8ztI8q0JbeD8q6G40RObejn5VL2kc4iJMBRNRZFM/aii+QfugID/N5P1TZgG9TmsHHputIaMDwY94NjvVAArLSw0MVEwcyJQGoptHs+wT6VS5jAeCSNB7kbfzcimj5d2lIMiKY8GpLfoyBpfYPlrjfvbBfMyUVA2XoAvlIegoby8zj12d+/F9UlsrRBF/vHH9DtT39w4+9+DE+CvsLkW2f9hSvWDdQ9VUsSl0hB0u/F0fMn5+AZtjfgXpLiDTi7JpQ==
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=1I6IJq1llxyLz6xA3Y4uEAAoP7nN1eUIGID5OmAJZRY=; b=svZ6YBdRe009ANoXwrUxbtwznbe8PBANJYGyRdBuj68glw23S2s9Gfb2aN6Fr6P3kFwfQRTXvet8xQXgCBlztxM6d4kxso/+IBjnWDwy74P45w8mCVsLDihMvuSyTuMXJ+qiylDMzXPjr4hK/cIJxzFvypv36378ariWMTFqrd0=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2126.namprd11.prod.outlook.com (2603:10b6:301:50::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Fri, 22 Jan 2021 12:46:28 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::14a1:29eb:e708:d7e6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::14a1:29eb:e708:d7e6%6]) with mapi id 15.20.3784.015; Fri, 22 Jan 2021 12:46:28 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "julien.meuric@orange.com" <julien.meuric@orange.com>
CC: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "roll@ietf.org" <roll@ietf.org>, "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>
Thread-Topic: RtgDir Review: draft-ietf-roll-unaware-leaves-23
Thread-Index: AQHW1I7tt5lHkfm/+06/YB+hP8LlM6n8oXNAgDXtwICAATt28A==
Date: Fri, 22 Jan 2021 12:46:24 +0000
Deferred-Delivery: Fri, 22 Jan 2021 12:45:47 +0000
Message-ID: <CO1PR11MB48815D20FA35708599A51088D8A09@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <27211_1608221318_5FDB8286_27211_31_2_5764bbfa-dbd4-46a4-1fe1-00f4d75268a5@orange.com> <CO1PR11MB48811D674011D7557D6E7024D8C30@CO1PR11MB4881.namprd11.prod.outlook.com> <74d16086-de2d-a0e0-0e67-a0c3976c5259@orange.com>
In-Reply-To: <74d16086-de2d-a0e0-0e67-a0c3976c5259@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:759e:7ee4:c063:3dd6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d237a8bf-31bf-4f3c-10a9-08d8bed3bce1
x-ms-traffictypediagnostic: MWHPR1101MB2126:
x-microsoft-antispam-prvs: <MWHPR1101MB212680B2C0A4E22CBB829CC4D8A00@MWHPR1101MB2126.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xWOtKxG2nhANjPAhZ3HSyphoCCfeeEDqIk6FsvZG6BpolCIsf6QagFi2pTTqDE66+Mlkn6l5dVpj03YDy3XeRRVbNPXwp6aqgR+A9xk4OyTaLB/ulqXV3jeJC+DMGTpV1C2fz/ldrxJFTLqgHib3QXlavVJdcZFkr0E/bCqxzN3IFBJ005upW++Q4Is12URj68C9g3TV2N0sjdjaLFsOwLNai/7aTQVaATo7fVcuyzyV1tgchopEGIvHoaqMWDhSSqVsF/H7QT+Hly1ouCOrgCAUtWBt+AA5wewnr6jnZnsBieKQKAPoOdLRvDOo0H6fja/SUtBjMl7BSiKSnTMdnFjWqitpMp7syyEw1CCJMnCku0dN9Xk9kjhHloryA81Yy5RYNT2GkcJOO8HjE7LRQDuc30nfQXkLG8sVSVefxodM6/FmEa4xy9r8vpp+hiZiZMpjBFEFnphGMj5Zp2Yq2g==
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)(376002)(346002)(396003)(136003)(366004)(6666004)(2906002)(54906003)(8936002)(6916009)(7696005)(8676002)(33656002)(316002)(71200400001)(52536014)(478600001)(186003)(53546011)(6506007)(66476007)(966005)(9686003)(76116006)(86362001)(66574015)(66946007)(5660300002)(30864003)(66446008)(55016002)(64756008)(66556008)(83380400001)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?bFQ1NGdSZFRGOTlobkJYVHhTY0lmWU5XMlJKdE12Y3VzNW9KVjl1dTk0NElB?= =?utf-8?B?MFdCK3hCaGtlaTQrYk5BRjBmOGd6ZlRDWUVHVk41ZXQveUpqT296NkRwS2tx?= =?utf-8?B?dm9ndmM4MjRteUpuWHM1SWdRZk9yczVZMXlPRWpicFdyQXNldXJIWnFrejZ1?= =?utf-8?B?d3REbDF3djZ2YmlQRFpBdFBPMFJwLzcrc2ROVUNxU3hQbkIzSUt0R2FyZWZy?= =?utf-8?B?NkZtZFpsMkdIRERoNUovN3M3NmJRcC8ya1pXd294a3FhdDZpZStQREJCMEFi?= =?utf-8?B?dmw2c0tJcFlSZUFEUllMaGg4TVNydzFsNTArd3ZYMmFEdmxMNTBvRDV4b0lD?= =?utf-8?B?YStjRnk3QjM5UkNoOEFTWkZXUDFNYTdxQ3ZvVkQyb0dsR2FZb3JQTDAwcEtY?= =?utf-8?B?WVBXd0c5cnFCamdYRkljVm1SM0YxUDhKZktmUi90YUEzQ1IyaWtCTWZzbUcx?= =?utf-8?B?SEttWkkyN1k5UmJNdFU4aVg5bktFYWVjSTZ4blhxTk5nSXRqSkJqekQza0tZ?= =?utf-8?B?NGR2M1RrQUdLUXJ3aHBvRG5jZVpVeVZ4OExyZ0ZSeWNCNGVoNzdiZ1VmcllO?= =?utf-8?B?Ry8zdUlOdmhUNXEzeUdVeTMwbzI4ZFJ2dHg5NStXWEtqbzh1YllSalkzSWtJ?= =?utf-8?B?UWkxYnJCY2IxWGNpdmhKSzVJbzN2V29MaDFMOTNORy9hcjlZRmd6OWY2VlRM?= =?utf-8?B?VUMzYm02QU9LTGQyZTdoN3BnNkUzUURsRUxsVzlRTHd1eWQzZGQ2Z3JxWU5p?= =?utf-8?B?N2RyKzc0UmttOVVEREhOY1czalZMcGNvTkRYYmw3OTFhZ0tQRGFMZzh1endH?= =?utf-8?B?OFJaUkVQU2J4OXEzc25WYmRPTFNnb01kaGJNS0lTTjJobmFxV0lmUkR6ZWhF?= =?utf-8?B?WmxENjg1SkhZUi9iaUhzTGhla00rT3hyU00rcTVZbVlIeS90RTBnaEV1N014?= =?utf-8?B?NU1ocTlOYWEvOWxOcEN4aWFVVFBSUEFnQ2ZlQjFWcWV2enhVRGNDcUZJZFo4?= =?utf-8?B?Szh1MllUUHVVRGpHeVYrbVdDM1RXNFVDWjhsYXB1cEEra251VjlCRjZIVlRZ?= =?utf-8?B?UnR2Vm9HbGxkdmd0L21iK09MOFRhZlFaU0VzeThvQm1lTE01cWM1cmVPSlhw?= =?utf-8?B?SHpyUDRZTzZYTXNMOXQ0YndEb2dwN052THlZUmJqVzBxdWViR1Z5QmJ4NkU1?= =?utf-8?B?dC9pRjQraHV6cDFickJqMElpU28yMTJqeVdRVUFkTytkSk02K3hNSkxoTUtI?= =?utf-8?B?cXluaE5aTFRpT0JXWndxWFZaZURUaExidDN6aDQwUjRUR0NMWFRoSzQxVFk4?= =?utf-8?B?dmd4OHhacTl3T2FpRzdYd3ppK0hGcDBqV2gyRzFUSmdibjlOTFRuTW9Lemg5?= =?utf-8?B?UE1KdEtYUlNOekhHbEZDWDltdTNPTlNFU0FJSlZtZzROMXVQMUpVMDhIY0ds?= =?utf-8?B?UkxYQVk3eTkyRlJ6MDNZR0RIVmxFdHdrcFJ5azlkMkVPKzRYZ3FZemU5aUNC?= =?utf-8?Q?+2hJnn4y9FVybGwuI3i5kxSbOR6?=
x-ms-exchange-transport-forked: True
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: d237a8bf-31bf-4f3c-10a9-08d8bed3bce1
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2021 12:46:28.7724 (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: b2dAk7BMfehmlX9hxgKlPI4wN4K+6FbP1whtNBNkuU1mUW0ojUOyCPG92YFoPb1+aesBNe4aehuMmY2ddgsiXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2126
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/EalglFN3exHGWEfBBunQyINU3RM>
Subject: Re: [Roll] RtgDir Review: draft-ietf-roll-unaware-leaves-23
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, 22 Jan 2021 12:46:36 -0000

Many thanks Julien!

I guess we are getting ready for RFC editor process; I made the changes in the repo and published -30 for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-30

Please note that we already had changed section 12.6 based on a suggestion by IANA. 
I modified as follows:
"
12.6.  New Subregistry for RPL Rejection Status values

   This specification creates a new Subregistry for the RPL Rejection
   Status values for use in the RPL DAO-ACK and DCO messages with the
   'A' flag set to 0, under the RPL registry.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "IETF Review" [RFC8126].

   *  Initial allocation is as indicated in Table 5:

    +--------------------+-----------------------+-------------------+
    | Value              | Meaning               | Reference         |
    +--------------------+-----------------------+-------------------+
    | 0                  | Unqualified rejection | THIS RFC          |
    +--------------------+-----------------------+-------------------+
    | 1 (suggested in    | No routing entry      | [EFFICIENT-NPDAO] |
    | [EFFICIENT-NPDAO]) |                       |                   |
    +--------------------+-----------------------+-------------------+
    | 2..63              | Unassigned            |                   |
    +--------------------+-----------------------+-------------------+

               Table 5: Rejection values of the RPL Status
" 

Take care,

Pascal

> -----Original Message-----
> From: julien.meuric@orange.com <julien.meuric@orange.com>
> Sent: jeudi 21 janvier 2021 18:38
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; roll@ietf.org; draft-ietf-roll-unaware-
> leaves@ietf.org
> Subject: Re: RtgDir Review: draft-ietf-roll-unaware-leaves-23
> 
> Salut Pascal.
> 
> Sorry for the late feedback. For the sake of following-up, your
> responses and I-D updates address my concerns.
> 
> Please consider the following few nits.
> 
> A missing coma and a typo in section 4.2.2:
> OLD
>    This is the reason why the support
>    of [RFC8505] by the RUL, as opposed to only [RFC6775] is a
>    prerequisite for this specification)/; this requirement is fully
>    explained in Section 5.1.
> NEW
>    This is the reason why the support
>    of [RFC8505] by the RUL, as opposed to only [RFC6775], is a
>    prerequisite for this specification; this requirement is fully
>    explained in Section 5.1.
> 
> In section 11: s/the overusing that channel/overusing that channel/  [or
> "the overuse of that channel"]
> 
> In Table 5 of section 12.6, the allocation for the [EFFICIENT-NPDAO]
> work-in-progress should rather be referred to as "to be defined".
> 
> Thanks,
> 
> Julien
> 
> 
> On 18/12/2020 15:11, Pascal Thubert (pthubert) wrote:
> > Salut Julien:
> >
> > Many thanks for your review!
> >
> > I committed the changes that I understood in https://github.com/roll-
> wg/roll-unaware-
> leaves/commit/d029d605fe4dbfa2ff1c444210fa67f923b715e4
> >
> > For your convenience, I also published an update for you to visualize the
> changes:
> > Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-28
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-
> 28
> >
> > Please let me know if there is more to be done.
> >
> > For the deep review discussion, please see below.
> >
> >> *Comments:*
> >>
> >> I am not an LLN expert, but I find the I-D convenient to read thanks to the
> >> appropriate (but numerous) references. I just feel that a few sections
> deserve
> >> some clarification to improve readability and that flag number selection
> >> doesn't really follow the expected process.
> > Cool, let's see how we can make things (even 😉) better.
> >
> >
> >> *Minor Issues:*
> >>
> >> - Sorry if ask questions on implicit contexts that are obvious to LLN people,
> >> but I am confused in section 3 with that "6LR that acts as a border Router
> for
> >> external routes": does it advertise towards the RPL domain? Does it talk to
> a
> >> peer 6LR that is also a RPL Router? Is that particular router necessarily the
> RPL
> >> Root?
> > There were similar comments and I already made some changes:
> > 1) added a picture that hopefully helps here
> >
> >          ------+---------
> >                |          Internet
> >                |
> >             +-----+
> >             |     | &lt;------------- 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
> >
> >
> > To clarify more I changed section 3 as follows:
> > "
> > 3.  RPL External Routes and Dataplane Artifacts
> >
> >    RPL was initially designed to build stub networks whereby the only
> >    border router would be the RPL Root (typically collocated with the
> >    6LBR) and all the nodes in the stub would be RPL-Aware.  [RFC6550]
> >    has the provision of external routes with the External 'E' flag in
> >    the Transit Information Option (TIO).  External Routes enable to
> >    reach destinations that are outside the RPL domain and connected to
> >    the RPL domain via RPL border routers that are not the route.
> >    Section 4.1 of [USEofRPLinfo] provides a set of rules summarized
> >    below that must be followed for routing packets from and to a
> >    external destinations (targets in RPL parlance).  A RUL is a special
> >    case of external target that is also a host directly connected to the
> >    RPL domain.
> > "
> >
> > Does that help?
> >
> >> - The text in section 6.2, as well as figures 3 and 4, use the F and P flags as
> if
> >> the bit numbers were defined, though their number is only "suggested" in
> the
> >> IANA section. If no early allocation process happened, it is inappropriate
> to
> >> assume the to-be-allocated bit number in the body of the document.
> > At this stage, we already made a pass with Amanda Baber (IANA).
> > A change would be pure form to be undone by the RFC editor.
> >
> >> - Section 6.3 reduces an 8-bit field to a 6 bit value. It would be worth
> >> mentioning that it sounds reasonable because the associated registry
> relies
> >> on standards action for registration and only values up to 10 are currently
> >> allocated.
> > Good point; done.
> >
> >> Furthermore, is there an update of that 6-bit space split to map the
> previous
> >> ranges? If the answer lies in the IANA section, then a few words would be
> >> welcome in section 6.
> > Aïe, I do not understand the question. We used to map 1 to 1 the ND status
> to RPL status, but after a discussion with Alvaro we found that embedding
> was better.
> >
> >
> >> *Nits:*
> >> ------
> >> Overall
> >> ---
> >> - RPL-[An]aware, RAL and RUL are preceded most of the times by "a" [OK
> if
> >> pronounced "riple", "ral", "rul"], but sometimes by "an" ["are
> >> pi..."]: please pick one and be consistent.
> > Done. We say a RPL, a RUL, a RAL, and an RPI.
> >
> >> - Any reason why "Host", "Hop" and "Router" are often written with a
> capital
> >> H/R?
> > Hum I thought I cleaned that up for the most part. Doing another pass I do
> not find much.
> > I use the uppercase on Hop-by-Hop because that is what RFC 8200 does.
> Same for 6LBR, 6LR, 6BBR, etc... else I used lowercase
> >
> >
> >> - RFC 2119 keywords SHOULD be used more often for an IETF standard
> track,
> >> it sometimes feels that the text is written to circumvent them.
> >> E.g., section 4.2.1 uses a wording based on "requires... if and only if...";
> >> section 4.3 describes a behavior without any normative keyword; section
> 5.1
> >> says "needs to", "is expected not to", "is suggested to"; etc.
> > There's more here than meet the eye. Remember that we extend existing
> work in RPL, ND and IPv6. The reason for the wording is that the MUST or
> SHOULD is already written in an RFC and we do not want to paraphrase std
> track text here.
> >
> >> ------
> >> Section 1.
> >> ---
> >> - The phrase "terminate packets" feels odd: is "terminate paths"
> intended?
> > This is gone already
> >
> >> - s/expectations/requirements/
> > Done
> >
> >> - The term "change" is used several times in the section summary though
> it is
> >> a bit loose: depending on the situation, "modify" or "extend"
> > There's both; we actually are more specific in the sections. I found one
> place where I did a replacement.
> >
> >
> >> would be more specific (the former may impact existing implementations,
> the
> >> latter does not).
> > Yes this is when we use "update".
> >
> >> -  OLD
> >>       Section 8 presents the changes made to [RFC6775] and [RFC8505];
> >>       The range of the ND status codes is reduced down to 64 values, and
> >>       the remaining bits in the original status field are now reserved.
> >>   NEW
> >>       Section 8 presents how [RFC6775] and [RFC8505] are used; the
> >>       range of the ND status codes is narrowed down to 64 values, and
> >>       the unused bits are reserved.
> > This was the goal when I wrote RFC 8505. I missed tiny things and had to
> perform updates which are listed in " Enhancements to RFC 6775 and
> RFC8505". Because of that this document updates RFC 6775 and 8505. Sadly.
> >
> >> ------
> >> Section 2.
> >> ---
> >> - s/Neighbor solicitation/Neighbor Solicitation/
> > Done
> >
> >> - s/Information solicitation (DIS)/Information Solicitation (DIS)/
> > Removed
> >
> >> ------
> >> Section 3.
> >> ---
> >> - s/The RPL Root tunnels the packets/The RPL Root tunnels data packets/
> >> [unless we're talking about control packet]
> > Done
> >
> >> - s/forwards the original (inner) packet/forwards original (inner) packets/
> > Done
> >
> >> ------
> >> Section 4.
> >> ---
> >> - s/Neighbor solicitation (NS)/Neighbor Solicitation (NS)/
> > Done
> >
> >> - s/6LN functionality in [RFC8505]/6LN functionality from [RFC8505]/
> > Done though unconvinced. Let's see what the RFC editor ends up doing.
> >
> >> - Section 4.2.3 summarizes the main use case of the ROVR though its use
> here
> >> is a bit different: why not focus the paragraph on the latest sentence and
> >> bring a correct topic balance into the section?
> > This section describes RFC 8505. It hints about how we use it in the rest of
> the spec but that's not the main goal.
> >
> >
> >> ------
> >> Section 5.
> >> ---
> >> - s/with a CIO/with a 6CIO/
> > Done
> >
> >> - s/the Root terminates the IP-in-IP tunnel at the parent 6LR/the IP-in-IP
> >> tunnel from the Root terminates at the parent 6LR/
> > Done
> >
> >> ------
> >> Section 6.
> >> ---
> >> - s/between the 6LR and the RPL Root/between the RPL Root and the 6LR/
> > In both directions in fact
> >
> >> - s/encodes it in one of these reserved flags of the RPL DODAG
> configuration
> >> option/allocates a new one in the RPL DODAG configuration option/
> > That sentence was reworded since -23. But the allocation game is for IANA
> section. Arguably  what matters to the implementer is the bit position.
> >
> >> - s/values zero (0) to six (6)/values from zero (0) to six (6)/
> > Done
> >
> >> ------
> >> Section 7.
> >> ---
> >> - The section title should point to the draft title ("Efficient Route
> >> Invalidation") rather than the draft name which will be replaced by an RFC
> >> number at publication time.
> > Point is, both drafts will publish together and this is to help the editor to
> the replacements.
> >
> >> - s/hop by hop/hop-by-hop/
> > Done
> >
> >> ------
> >> Section 8.
> >> ---
> >> - Spacing inconsistency on the section title.
> > Fixed
> >
> >> ------
> >> Section 9.
> >> ---
> >> - In section 9.2.2, the capital T is missing on "the" for steps 4 and 5.
> > Fixed
> >
> >> - s/Lifetime. e.g./Lifetime. E.g./
> > Fixed
> >
> >> - s/6LoWPAN ND related reasons/6LoWPAN ND-related reasons/
> > Fixed
> >
> >> - s/An error injecting the route/An error when injecting the route/
> > Not sure; since several native speakers reviewed it I'd rather leave this as is
> >
> >> - In section 9.2.3, the capital T is missing on "the" for steps 2 and 3.
> > Fixed
> >
> >> ------
> >> Section 11.
> >> ---
> >> - s/supporting th extension/supporting the extension/
> > Fixed
> >
> >> ------
> >> Section 12.
> >> ---
> >> - s/doesn't/does not/
> > Fixed
> >
> >> ------
> >>
> >>
> >> Regards,
> >>
> >> Julien
> >>
>