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: A0AtBQDNxQpgkI9dJa1iHgEBCxIMQIMiUX1bLy+EQINIA44OA4EFjgyKBoFCgREDVAsBAQENAQEjCgIEAQGESgIXgWECJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgBC4VzAQEBBA4VEQwBASMGCQUBCwQCAQYCEQQBAQECAiYCAgIwFQgIAgQOBQiDHgGCVQMuAQ6WeZBrAooldoEygwUBAQaBNwKDZxiCEQMGgQ4qgnaEA4JOg3QmG4FBP4ERQ4IhNT6CXQEBAgEWgSwcFYMCNIIsgU8KaQYBYwQUDg0DEQgGAhQOURITCCkCEQEFASAOAWCPTIMsh2CMEZA3gQgKgneJMJJdgyuKM4VjiUOFcJMrc4IHhx2BepFyhEMCBAIEBQIOAQEGgW0hgVlwFRqDClAXAg2OIQwOCYNOhRSFRHQ3AgYBCQEBAwl8iwoBAQ
IronPort-PHdr: 9a23:MQMqGxS9fw5xRjrEFtmuGjoNLtpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQBNuJ7OhNjeXb9avnXD9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7VuHS04jNUERL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jBDOpyhF
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: lT54gRdTF99hnBXTxScIfYNW2RJtMvcus5oJV9uu944IA0WB+xBhkei4+bNAF0f8gzfTCYEGVN5et/yJjOoz6DpKkqvogvc824myJnXs5IgQfOrs5Y1yOEjbpWrAseurHZqkz6uwtDl1wv6vbiPDZAtPO0Rp/7+sdNUCqSxPnB3IKtGarefr6FmdZl2GHDDh5J/7s76bQp/2kZWwoxkqat6ie+PDBB0Abvl6sKIpYReADRYLhh8MSrw1l50+wvX2aDvlL50oD5xoICa+cFy7B39RCh8ASZFWP1Ma7qCvoVD2oGlGaYorPL00pKXYPWwG9rqBjgXFIcVmR3F1P8JfKfR/taA3CR2ikBMfsmG1HKmZI27Y9RbMtU8iX9nKEaecI6xnXqNNgItjJBjzD3kKY4dv3TkAGKQrwhpoDnceZUyVx8LrgFRycB4eh77bgUfrYNG/3uINvhT5q3yGUy30o28dRvtx95+WXKjo8ubYRjY3IkIQi1brBcb1XcivhJK5Io3vWoLh1L93NG/ar9YFgz9f6VTLUC3bm6AOKLd2e7h7pg6E3QDlELlW9QLwuyd3dd6grqYNi7dr+74Rkm9UDDHNcW3jVLpcoNDXbl791agKPDaLg8uzwG8RZREPSbx9q3snVbdOLSgoMdhbMKISN2hnaqWIfRDzehEZlD685JHYR/biHsLhekM+OxrSM+q5YmYHy/tE0ghEu7Mx5Mhq9Naa/9lNpCxiaUTPRPAgCfeB1VqevzxUDcCqFIdZ8K8u2YTPuUDjGyV+mWC3TW4UCZ8lapupA+knuV9BF6HVTYRtvVoGlldvgt/mb+OL8TafQZSEsy8oBmeLM5qc5reOJXpHzrP4YO6XMsL9t4bwDogp7NvLyYRbjW0quebGVyBbx6E5t/iF4+huzp1brBj0IiSo212jyWQUAdO+dJM6+xMJLhMKHqynhNZLTiOBWZwqXVZeDThLbt3zh40R4TGCLXThK41TY8vgx8xZq9wOaiG7Xwzi+HFp0jWh2G1TJgbn9NLTnMoKzh9PMJtKXRSNzHGlFCX9mu3ONSESAIJVmg4N1uP1JU08HcGlRLXAY7y92FRz03YGDHVlEtwkpRyk9d2EO+4XgqYze9iCB+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 > > | > > +-----+ > > | | <------------- 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 > >> >
- [Roll] RtgDir Review: draft-ietf-roll-unaware-lea… julien.meuric
- Re: [Roll] RtgDir Review: draft-ietf-roll-unaware… Pascal Thubert (pthubert)
- Re: [Roll] RtgDir Review: draft-ietf-roll-unaware… julien.meuric
- Re: [Roll] RtgDir Review: draft-ietf-roll-unaware… Pascal Thubert (pthubert)