Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 March 2020 14:38 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 456403A085A for <roll@ietfa.amsl.com>; Tue, 17 Mar 2020 07:38:56 -0700 (PDT)
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=VNgwYuBV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=koTQ5NJ5
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 IXmPZrBVF_IA for <roll@ietfa.amsl.com>; Tue, 17 Mar 2020 07:38:53 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9465E3A0858 for <roll@ietf.org>; Tue, 17 Mar 2020 07:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19890; q=dns/txt; s=iport; t=1584455933; x=1585665533; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=; b=VNgwYuBVhxr7egIHa7zXfu/CZFh+Mr3Uo94RPB+T+C1ciGRKLOfJp8+L S2mCO1+SlleU8PORGyXD7C2KnPznq4YnhTVZD4OREh4rda9BOeuj4E84V fP3AVFByBsqtE8w/G80hvjuylSamB+52571XJT4RScn3Xp+AyvwKo2ku/ A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A9ZLxjB1ICBnKdlJWsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7BwBG4HBe/51dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqhBaDRQOKc06CEYEBlxeBQoEQA1QJAQEBDAE?= =?us-ascii?q?BIwoCBAEBhEMCF4F9JDgTAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQIBEhE?= =?us-ascii?q?EDQwBATUDCwQCAQgRBAEBAwImAgICMBUICAIEARIIGoMFgkoDDiABDqF9AoE?= =?us-ascii?q?5iGJ1fzOCfwEBBYEzAoQCGIIMAwaBDiqFIIcOGoFBP4ERR4IYNT6CZAICGoE?= =?us-ascii?q?vCxEVgnoygiyNdoJ7n1IKgjyNJIQ4hTeCSjGHd4RQjASPBYFOmhACBAIEBQI?= =?us-ascii?q?OAQEFgWkigVhwFYMnUBgNjh0MF4NQhRSFQXSBKYsugkEBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,564,1574121600"; d="scan'208";a="727041424"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2020 14:38:51 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 02HEcoa9030651 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Mar 2020 14:38:51 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Mar 2020 09:38:50 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Mar 2020 10:38:47 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Mar 2020 10:38:47 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DTxlvq5KBDH/ZAA4ImPwKAzY3KA/Q3t2ZW5Kc5Sm6gLOO12VzxTFNMc+Eva6K1?= =?utf-8?q?Rh+YWp+J7hoa9OpduQWwL/k2uhJdVu0oF4aMZcnpFaZNUKVJhRHMEIziuPNS8Xu9v?= =?utf-8?q?ZAJH6/a065YIMolVCA7oIidqZ3Onk8+v9r8g8v7bpSED3YwvehhV24dKNQdIHtrnS?= =?utf-8?q?aTmNp7qE4eZoYL11lTXvTYVTRyz7zz3XalU3NFli5ziqOl/nF47KU6/aYJp5YrqvY?= =?utf-8?q?/8DT8g8yrVRyuXtkck9ZE0kAtRqEZWavAmJy8iBbl2oUJrAw5HmYORd+HRGgGA+Ko?= =?utf-8?q?MdSjFMJ9PbKjSz39R93hA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DXWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=3D=3B_b=3DZ9rhIQ?= =?utf-8?q?gHvzYXVZ4krrZx31Ztkgkl4XHwZVl+TLT4HvCpg8JNy1gi3KgAmcqjAsC68ZJLHnz?= =?utf-8?q?obXmVG1OrDrnseTe4wew2LP5qRKnxQWb4cXLf4z4PCwVHWsK3JziPqBld0nfb+c+y?= =?utf-8?q?oNCvgcBphldomNIMSFU88NWeDDDxoXrVD+wE4azaCpH6oJmaBgM6/bEdG4CQ85YoI?= =?utf-8?q?sWKq47XAGeZ7Z3EJO1h0x1NuyZ4apiFtCige3aRhKgS90r+r9GSTOVNq68Hp3WXYC?= =?utf-8?q?B97dib4ZWSUdNHw5DRmH6q/YO5X3+CmncKFkGaFvHBzImM9+ZQAc7c09lxeF1katQ?= =?utf-8?q?QvzaJK9NZYQ=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DXWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=3D=3B_b?= =?utf-8?q?=3DkoTQ5NJ5JyULVooaqdjeSOBkgVBKJxuqPEgsdqaoyR7f+APDQykElcE4PmQ8vx?= =?utf-8?q?mjVgHg6yxXQEJdMP2sP/Hvb7VhPGLMwrPLXAhGFBH7cOeIrpIANg1SyGsKAmTgBEm?= =?utf-8?q?Vwtee21t6j0A6KLXQUbr6ppqN/+EEWghI2FwPS7VfTC4=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4174.namprd11.prod.outlook.com (2603:10b6:208:154::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.14; Tue, 17 Mar 2020 14:38:46 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020 14:38:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
Thread-Index: AQHV+wgp0rlICDWRl02cnIGxwamUR6hKIoVQgAFtDYCAAQy0EIAAQEPQ
Date: Tue, 17 Mar 2020 14:38:16 +0000
Deferred-Delivery: Tue, 17 Mar 2020 14:37:34 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB35650108ADD7C22D67C6173BD8F60=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158410288420.3321.7400803802055697408@ietfa.amsl.com>, <23773.1584304056@localhost> <3A00F2FF-C119-496C-BC53-87DBD6C375B4@cisco.com> <9766.1584384223@localhost> =?utf-8?q?=3CMN2PR11MB35659BFC7F16BEBF34FEBEC0D?= =?utf-8?q?8F60=40MN2PR11MB3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMN2PR11MB35659BFC7F16BEBF34FEBEC0D8F60=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:957:248:1e11:16b5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6fa6a2dd-c031-48e3-b6c7-08d7ca80e62d
x-ms-traffictypediagnostic: MN2PR11MB4174:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB4174C069C7A76CE094B6DA04D8F?= =?utf-8?q?60=40MN2PR11MB4174=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNDYwMDIpKDM3NjAwMikoMTM2MDAzKSgzOTYwMDMpKDM2NjAwNCkoMzk4?= =?utf-8?q?60400002=29=28199004=29=2830864003=29=286666004=29=288676002=29?= =?utf-8?b?KDk2ODYwMDMpKDE4NjAwMykoNjUwNjAwNykoNzY5NjAwNSkoNTM1NDYwMTEpKDI5?= =?utf-8?q?06002=29=28316002=29=2852536014=29=28110136005=29=2886362001=29?= =?utf-8?q?=288936002=29=282940100002=29=285660300002=29=2815650500001=29=28?= =?utf-8?q?81156014=29=2881166006=29=2866946007=29=28966005=29=2855016002=29?= =?utf-8?q?=2866574012=29=2876116006=29=2866446008=29=2866556008=29=28647560?= =?utf-8?q?08=29=2866476007=29=2871200400001=29=28478600001=29=2833656002=29?= =?utf-8?q?=2821314003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4174; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?Ug0l+j2U4RHIbEB2wEVUAUKHTqjQDVt?= =?utf-8?q?hZCb0bId8kA7N6VKO41vIHygCfEakI5QOOpzRujd+h8q0wh07dWzH6bvSr47qkGvg?= =?utf-8?q?TCcVKV/h4qvP+IyUSKtYSIkAoxvXJVe8i90ogAnf1Iljl8uuEfkm5BqmeCPQRwh1l?= =?utf-8?q?JN9A52GKGO8OTO+D/rpvVcXdIbGxw0+Tfywemmp1YmD1V9oM0ptuFvVP2Uvt2J/9p?= =?utf-8?q?heHrOzW0NmmtJU2JcMSAoxGdTrkFVH7mrgCZuIaY/qH02gZL0SPWTN/M43V4XOBEt?= =?utf-8?q?+jORfP98/1GNTwz3osUULv1VA4g8cGIcVyGlCtrjRaO8TEmJyhkFLk8FgwMFsbCQ4?= =?utf-8?q?cFw3kuhQB5Ok5gdKTftpR3ZNamm2umsOXT4uGcglSBx/gv2mwwfFyEm3o93+TLD9o?= =?utf-8?q?yvm77StVxmyvZXWhKRuiH6jXAzEs8ig+a0ZNUs2IeUaU78wo13LIC5laX3SQRZMZq?= =?utf-8?q?VvRkdoYnE7CEqKuwyJ5Qc8zWGnui5r4wxdSFxdHdhfnt7XiSXScFodes/sZuTcx5/?= =?utf-8?q?dV1YUjlYJRVmhCk7LdJgrEc8p?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?HTsf22OWXq9s3x0FIYS/7LqYAlQ5GO?= =?utf-8?q?1oblMQXsvAjWhM2xZONWcg7qfxNb5wiBOxo++UYomJVr9iXEKt78w1hrgtESP1zlT?= =?utf-8?q?oCbKqFqNm3HGVB8lvlTJloFiXuIs2KoPpxH3Ej0b4blsarZeaKQPACyYSrL14jdck?= =?utf-8?q?RYNlZpiGlT4eRg3X7oaGuPxxZtQrkRj/IWAS0QQZhvsHxQY5nC8tjw=3D=3D?=
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-Network-Message-Id: 6fa6a2dd-c031-48e3-b6c7-08d7ca80e62d
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 14:38:46.1345 (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: =?utf-8?q?JZVhhD/gxNuxILH1neLpi?= =?utf-8?q?N9IwuthbLN2rFsE509erWgSeGFb4kELX0+seq31kipEKsvOD6CacCw8R536tQmdaw?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4174
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Y_Gu-fvHbGqUbPeApQ_4BpqwN-c>
Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
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: Tue, 17 Mar 2020 14:38:57 -0000

Hello again Michael

I applied a number of your recommendations and published 13.
I hope that the remainder of the discussion can be addressed during WGLC, if any.
Please see   https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-13 
 
Take care

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 17 mars 2020 12:27
> To: 'Michael Richardson' <mcr+ietf@sandelman.ca>ca>; roll@ietf.org
> Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> Hello Michael,
> 
> Now going through your questions below:
> 
> > -----Original Message-----
> > From: Michael Richardson <mcr+ietf@sandelman.ca>
> > Sent: lundi 16 mars 2020 19:44
> >
> > 1) I notice the Abstract is a single complex sentence.
> >    I think we should split it up somehow.
> >    I will think on this after reading it all through.
> 
> Yes, I use your proposed change, keps the split, and moved one sentence
> down.
> 
> 
> >
> > 2) I have a bunch of typos/missing words that I'll commit directly to github.
> >
> 
> Thanks!
> 
> > 3) Should we say:
> >
> >    A RUL is a plain <xref target="RFC8504" /> Host that needs a
> >    RPL-Aware Router to obtain routing services over the RPL network.
> >
> > that is, insert RFC8504 here?
> > Or should we actually say RFC8504/RFC8505, because we depend upon
> EARO?
> > I'd like to get Carsten to review this actually, as we are really
> > updating what it means to be a "Host" on a constrained network.
> 
> For 8505, the next sentence does it. I like your suggestion to add the reference
> and changed "plain host" to "IPv6 host".
> 
> 
> >
> > How can we split this up into three sentences:
> >    This specification leverages the Address Registration mechanism
> >    defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to
> >    interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to
> >    request that the 6LR injects the relevant routing information for the
> >    Registered Address in the RPL domain on its behalf.
> >
> > I think that this paragraph (3.2.1) should get turned into part of the abstract:
> >
> >    This document specifies how the "R" flag is used in the context of
> >    RPL.  A 6LN is a RUL that requires reachability services for an IPv6
> >    address iff it sets the "R" flag in the EARO used to register the
> >    address to a RPL router.  Conversely, this document specifies the
> >    behavior of a RPL Router acting as 6LR depending on the setting of
> >    the "R" flag in the EARO.  The RPL Router generates a DAO message for
> >    the Registered Address upon an NS(EARO) iff the "R" flag is set.
> 
> I really like to keep the abstract short.
> 
> 
> >
> > I wonder if the word "Conversely," is needed.
> > Maybe:
> >    A 6LN is a RUL that requires reachability services for an IPv6
> >    address. It sets the "R" flag in the EARO in order to register the
> >    address to a RPL router.  This is described in RFC8505.
> >
> >    This document specifies the behavior of a RPL Router that processes
> >    EARO messages that have the the "R" flag set in the EARO.
> >
> > Not sure if this is abstract content, but I like the above.
> > You really like the word "Conversely" :-)
> >
> 
> I do but we can remove/change if not appropriate
> 
> > I am concerned that there is so much repeating of 8505, that this will
> > confuse some reviewers.  I guess we do Update 8505, but maybe we
> > should hit them a bit harder on the head that they need to understand it first.
> 
> This is really the RPL counterpart of RFC 8505, and we need to show the
> matching operation each time it occurs.
> 
> > section 4: I keep wondering if we haven't created a new Storing-Mode
> > MOP here,
> >         that should get a new MOP value (or mopex) value.
> >         But, I see that 6.3.1. contains the compromise text we worked
> > out at IETF106.
> 
> Rahul discussed a real new MOP in a parallel thread. Interesting stuff...
> 
> 
> >
> > let me think: a storing root that does not set the P bit (because it does not
> >     support this functionality) will cause 6LR that support this to not
> >     support RUL processing, and not support RULs.
> >     Should such 6LRs also essentially not do RAs in that context?
> >     Does this also enable RFC8505/EARO processing?
> >
> > I find section 4 really dense, and I wonder if it wouldn't be better
> > to move sections 4 and 5 later in the document, so that we are referring
> back.
> > I'm not sure here.
> 
> That would be really difficult. Section 4 is a collection of pointers to the next
> sections as an introduction of what comes next.
> 
> >
> > section 6.1:
> >    In order to obtain routing services from a 6LR, a RUL MUST implement
> >    [RFC8505] and set the "R" flag in the EARO option.  The RUL MUST NOT
> >    request routing services from a 6LR unless the 6LR originates RA
> >    messages with a CIO that has the L, P and E flags are all set as
> >    discussed in Section 3.3.1.
> >
> > -> I think that rather than have MUST NOT, which I think does not lead
> > -> to
> >    good interop failure results, I suggest we write:
> >
> >    A RUL that receives a CIO from a potential (6LR) router that has the L, P and
> E
> >    flags set, SHOULD set the "R" flag in the EARO in order to request routing
> >    services from that 6LR.
> 
> Well, that's only if the 6LR wants to use that guy. And you're reversing the
> meaning. I tried to say that a router can be used for this spec iff its sets all the
> bits. I read your text as saying that if a router sets the bits then  the RUL
> SHOULD use it....
> 
> 
> >    A RUL that has multiple potential routers SHOULD prefer the router that
> >    can provide the desired routing services.
> >    If there are no available routers, the connection of the RUL fails.
> 
> Kept it, though a bit on the obvious side
> 
> 
> >
> >    (XXX- Can the RUL use the EARO process in the absence of L/P/E to signal
> >    the error?  I think that deployment of 8505 without this document is a
> >    very small window, so this won't work in general)
> >
> 
> Yes. A RUL can register to many routers, to get a DODAG back. It may in
> parallel register to routers that to not have the bits set, so it can talk to them.
> But it will not get routing services and the "R" flag will not be set in the NS and
> NA 's EARO
> 
> >
> > ...
> >    The RUL MUST register to all the 6LRs from which it requests routing
> >    services.
> >
> > section 6.2:
> >    A 6LR that is upgraded to act as a border router for external routes
> >    advertises them using Non-Storing Mode DAO messages that are unicast
> >    directly to the Root, even if the DODAG is operated in Storing Mode.
> >
> > yes, but it should only request them from routers which support R, right?
> 
> The external route is a general term, and the route can be learnt in many ways.
> E.g. redistribute an IGP.
> You're correct that it means the 'R' is in the case of a RUL learned via 6LoWPAN
> ND.
> 
> >
> >    The RPL data packets always carry a Hop-by-Hop Header to transport a
> >    RPL Packet Information (RPI) [RFC6550].  So unless the RUL originates
> >    its packets with an RPI, the 6LR needs to tunnel them to the Root to
> >    add the RPI.  As a rule of a thumb and except {FOR} the very special case
> >    above, the packets from and to a RUL are always encapsulated using an
> >    IP-in-IP tunnel between the Root and the 6LR that serves the RUL.
> >
> > I think that this should reference [UseOfRPLinfo] section 7.1.4,
> > section 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4.
> >
> 
> Good
> 
> > section 9.1:
> >    In a same fashion, if an additional routing protocol is deployed on a
> >    same network, that additional routing protocol may need to handle the
> >    keep alive procedure for the addresses that it serves.
> >
> > I believe that this might scare our routing colleagues into thinking
> > that we intend to deploy things in parallel on LLNs.  Do we need to say this at
> all?
> > (I understand that you are just expressing an outward requirement on
> > anyone that wants to do this.  Maybe we can put this in a section of it's own
> so
> > that someone can point to it in the future?   Quite reasonable, someone
> could
> > attach a non-constrained wired network on the edge of an LLN, and run
> > OSPFv3 or something there.  But there would be no overlap with the
> > LLN)
> 
> Yes, that would be a complicated network... I believe the text is needed, but if
> you like we could move to appendix or something.
> 
> >
> > section 9.1.1, I think that the column that says "6LN" should say "RUL"
> instead.
> >         Yes, 6LN is not wrong, but I think it's not helpful.
> 
> Yes, I like your proposal
> 
> > Do we need to say something about LLNs which do not have a 6LBR?
> > Or is this degenerate case self-evident?
> >
> > section 9.2.1: "By the 6LN" -> "By the RPL unaware 6LN"?
> 
> Anything as long as 9.2.1 and 9.2.2 are homogeneous...
> 
> 
> >
> >    *  The 6LN can register to more than one 6LR at the same time.  In
> >       that case, it MUST use the same value of TID for all of the
> >       parallel Address Registrations.
> >
> > I'd like to motivate this statement, I think it should reference
> > RFC8505 section 5.2.  Just so that no part of this process is "new"
> 
> Cool
> 
> 
> >
> > >   Even without support for RPL, a RUL may be aware of opaque values to be
> > >   provided to the routing protocol. If the RUL has a knowledge of
> > > the RPL
> >
> > I just looked to see if we return RPLInstanceID in CoJP, and we don't
> > :-( Someone could write a document in RPL to add that.
> 
> Do you think we should do it here? It's doable...
> 
> 
> >
> > >   A RUL that places an
> > >   RPI in a data packet MUST indicate the RPLInstanceID that corresponds
> > >   to the RPL Instance the packet should be injected into.  All the
> > >   flags and the Rank field are set to zero as specified by section 11.2
> > >   of [RFC6550].
> >
> > It has never been clear to me how much security isolation
> > RPLInstanceID should have.  Is it as strong as 802.1Q VLAN tags?  Or
> > is much softer, just a bit more interesting than IPv6 Flow?  If it's
> > intended to be as strong as VLAN tags, then there is an admission control
> control that the 6LR must do.
> 
> Could be made as strong. I mean a vlan is only as strong as the switches make
> it. You'd need different keys per instance since we use the same radio
> interfaces.
> 
> 
> >
> > >   Extended Duplicate Address
> > >   messages with the 6LBR is avoided if the RPL Root has indicated that
> > >   it proxies for it.
> >
> > I'm misplaced how the RPL root has indicated this.  Is it in the DAO-ACK?
> 
> See section 4, we could have a reference "
> 
>    RPL defines a configuration option that is registered to IANA in
>    section 20.14. of [RFC6550].  This specification defines a new flag
>    "Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved
>    control bits in the option.  The new flag is set to indicate that the
>    Root performs the proxy operation and that all nodes in the network
>    must refrain from renewing the 6LBR state directly.  The bit position
>    of the "P" flag is indicated in Section 12.2.
> "
> 
> Maybe we can say
> 
> "
>   message, but the exchange of keep-alive Extended Duplicate Address
>    messages with the 6LBR is avoided if the RPL Root has indicated that
>    it proxies for it using the "P" flag in the RPL configuration option
>    (see Section 4).
> "
> 
> >
> > 9.2.2:
> > >   *  RPL Non-Storing Mode is used, and the 6LR indicates one of its
> > >      global or unique-local IPv6 unicast addresses as the Parent
> > >      Address in the associated RPL Transit Information Option (TIO).
> >
> > I think that this is an instruction that RPL Non-Storing mode is TO BE used,
> > (not a conditional sentence).   I suggest we number these points so that
> > implementers can argue about them better, and make them all more
> > declarative.
> > There is a commented out sentence in the XML, which I think we can remove.
> 
> Cool. We should do the same in 9.2.1 and 9.2.3 then, no?
> 
> >
> > I understand the use of "iff" throughout, but I'm not sure others will
> > notice it as other than a typo of "if".  I turned the next paragraph
> > into a numbered point, but maybe the trailing ';' now does not work.
> > I'm not sure that the reverse direction provides anything useful. Opinions?
> 
> I though it did, but OK without it.
> 
> >
> > Should the rest of the If/In case be changed to a section on 6LR processing
> > of DAO-ACK, and a section on processing of DCO?    Right now processing is
> > described by each role.  I'm for that, but I think we should split it
> > up as well by message.
> 
> 
> If needed...
> 
> 
> > Is section 12 RFC6550 multicast actually implemented by anyone?
> 
> We have use for it.
> 
> > Given MPL, I didn't think you needed both, but maybe I don't
> > understand multicast.
> 
> MPL is out of scope here. IMHO it's a more of a broadcast than a multicast. In
> ny fashion I do not see it as a replacement to RPL but as another protocol that
> can co-exist with RPL though both can live separately.
> 
> > Section 12 RFC6550 would have been something I would have removed for
> > 6550bis, so I wonder if we should be doing anything with it.
> 
> I have to disagree with that. Just like I disagree with other people about
> removing storing mode.
> 
> 
> > section 12.3, I think that instead of reducing the size of the Flags
> > field, I suggest that we say that we are allocating 4 bits of the Flag
> > field as the ROVRsize. (I found it really confusing to figure out btw)
> 
> Happy to reword but we are not allocating 4 flags, we are reusing the footprint.
> 
> >
> > ----
> > I wish I had time to implement this in unstrung and the Linux kernel.
> > :-( I need to clone myself.
> 
> That would be an interesting world : )
> 
> I published -12 with your changes and already picked some of the proposals
> above in the github.
> Please have a look and let me know when you do think we want more.
> 
> Many thanks again Michael!
> 
> Pascal