Return-Path: 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 79554120CF2 for ; Wed, 4 Sep 2019 23:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=W9iN9CEr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W7hrMOJ7 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 HFDj4eJsz4vI for ; Wed, 4 Sep 2019 23:30:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921D3120CAA for ; Wed, 4 Sep 2019 23:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63357; q=dns/txt; s=iport; t=1567665049; x=1568874649; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yNGGWEU+ejTeos+mk1ilsIGZRqKqEIreNBRH2+o3Hl4=; b=W9iN9CErsB/WBis+QUf5HUoWUYIiM7Hf5DsXAe7T0WATqhJqclEFIFcz QcYQ34/xtTcYRrErJUVOQWiDhbuMSa4bOkstfxQfKVcXScIpRCCaboQz4 0W8UhyYvMdsFYX3OBVrvAix0zp9JXtKjeffbmtMJE9qzKaAdBUsmoprRW c=; IronPort-PHdr: =?us-ascii?q?9a23=3AT9rJIRELnGvQ4/VFWROlg51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAAJq3Bd/5hdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4EWLyQsA21WIAQLKodoA4p1TYIPfo8MhWGCAYFCgRA?= =?us-ascii?q?DUAQJAQEBDAEBGAEMCAIBAYQ/AoI0IzgTAgMIAQEEAQEBAgEGBG2FLgyFSgE?= =?us-ascii?q?BAQEDAQEQFQYTAQElBwIKDwIBCA4DBAEBIQEGBycLFAkIAQEEEwgagnsEAoE?= =?us-ascii?q?dTQMdAQIMn1wCgTiIYYFyM4J8AQEFa0cBg2IYghYDBoE0hQCGeBiBQD+BEUZ?= =?us-ascii?q?RgUYHLj6CYQEBAoEnHB4lBgmDB4ImjEUPh36JEY5ICoIfhneHH4ZpgjSHOYQ?= =?us-ascii?q?eimWMT4EqgTiGQ5BbAgQCBAUCDgEBBYFnIQ2BS3AVGiGCbIJCDBeDT4UUhT9?= =?us-ascii?q?zAQmBH48lAQE?= X-IronPort-AV: E=Sophos;i="5.64,469,1559520000"; d="scan'208,217";a="620628050" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Sep 2019 06:30:07 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x856U63D016658 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Sep 2019 06:30:07 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 01:30:05 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 01:30:04 -0500 Received: from NAM04-SN1-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.1473.3 via Frontend Transport; Thu, 5 Sep 2019 01:30:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlWj1eWeBFT704qoyaKxj6L9UlXAmDgeNzJPtTYJXi7jmudZqj3W0tC5kSknvVS3z+LxCrPmOJ9fauZeOG4ZiaLFDcoH+yGsT24MkyENHWgauIN//5e+iQIB1k3dpqRwx9vrhT/QT6GfaRCH6V55QJt7qA0BAfZUk8NXsa+SDef2w36HYBdDxNFJ1ZtgixlapE8Bw41GstjXa6SL2K6byq1j96pLrxW2fz+TZwgK+Bsc173wtic0IxHzRY65c9ECtOLrrX9xWgQ1mcsbe2Hb8n6QC4Q8jXt74c/Jdff50oJeXLwW+faSBlzRrg4epGofvHq6T9sAgPZiLBbxBUdR8g== 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=pbaGAXiC1ZqxOf9X1bY6tEq0rUo678J2h/yhCsUjIsw=; b=UusDMkv7JC0Z/+9uStojI66Mg3MDZfNyE7zilzT0bwO7Ebs+xdYX0w8q2sPFJjOjKKvPqQjBA1oip4gmwVj2ly+6uAr2BXYlbeZYT7+BePmuyqtPrKqvuofvsTGfa9X+ToelgXua27uie7eksHyDZsBgvL5PEg43DnI/RziJJ0q+1+7KT4PspQyfCf+66J5EXyskyyn7Jbz7t8dTYTa+ZfCf5jgEH52BH7JMIE1PbdJ84h755WDkPI9wPM5phAsN5bf7aD2UkTFN4HStmXpjyoYXkNL6eunMn1GN3OjlROnAF6JtqbIWGymrSrctGUTdkcOoe51ZXKV8mVL5Zb54aw== 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=pbaGAXiC1ZqxOf9X1bY6tEq0rUo678J2h/yhCsUjIsw=; b=W7hrMOJ7nZ6mrcgLBb0DXlPrNYoLzlZaEE0iHlH1yYy5pmjDeEcqIOL+q2zVdxzefCrV1AV0dps5g/CwNcGgmrlw45hys8O/OQ+sMvmJi+EFgi9GJG1b7usueUf8qPepPmSb8Ua9EBpbPtcvysKbFfVAfCyYb0AqI7T+ZDvM6sk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2SPR01MB0035.namprd11.prod.outlook.com (20.178.251.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Thu, 5 Sep 2019 06:30:02 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.022; Thu, 5 Sep 2019 06:30:02 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] giving back MPDAO to RFC editor Thread-Index: AdVjB/JIrm5BouKOTamY5+QcgzHTjqccbzTnpxsrrVA= Date: Thu, 5 Sep 2019 06:29:38 +0000 Deferred-Delivery: Thu, 5 Sep 2019 06:28:38 +0000 Message-ID: References: , In-Reply-To: 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: [2001:420:c0c0:1003::a0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e43fcf7f-0533-46b5-0630-08d731ca7b8f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2SPR01MB0035; x-ms-traffictypediagnostic: MN2SPR01MB0035: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 015114592F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(189003)(199004)(25786009)(6116002)(790700001)(446003)(476003)(46003)(110136005)(316002)(11346002)(7696005)(99286004)(486006)(14454004)(6666004)(52536014)(966005)(5660300002)(45080400002)(478600001)(33656002)(256004)(14444005)(2906002)(54896002)(6306002)(55016002)(6436002)(6246003)(9686003)(236005)(53946003)(53936002)(229853002)(66556008)(66476007)(64756008)(66446008)(66946007)(186003)(606006)(74316002)(6506007)(53546011)(102836004)(76176011)(81156014)(71200400001)(71190400001)(8936002)(81166006)(86362001)(8676002)(7736002)(76116006)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2SPR01MB0035; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: L/29tpzm9lbRmWsUVJtR9CCHmHD00bruGUjSvKADAj3uTWKevrP/CKnQqj6Wcts6j5qzUcmntAcbTpHZpK/PhA6PfgA7MdvNKyvBOual/Jlw5dcpnuk3fLXHT3r1nS0nDGXhgdlv1RLgHmoTHM1iMpXkLRSIHbwDplIyXJOEzjEBbdkLS8men5HXkZA7A8B0dlK7AwqAr9SX4zYDpz6ILBKqlbB3So+4E/3G34FubQCeJkrdgv5/1y6zzV4FpDq9ZjiR0ZDw4GKEGjKICQSyF9D8Ww0CG+pNc6dOFH9MQ9P0Gx/56oBpjUTWEUnk8EePoY4/rnLdjdR5PoNpxmijjMPCo/fzkJqbexJ0gobpLebhrCHnAMNf7nsXfFHiFJPtDBriYnT9ARyaGpB4zDjlDbhimnpd/HCqPJlDfGjaeuQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565D2139143EFF0F43055E3D8BB0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e43fcf7f-0533-46b5-0630-08d731ca7b8f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 06:30:02.1450 (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: JwuV54SHuWkWhyvRV1HCsIWWr+jNvVIrs6SPDEe8t4wgVCTn6yiXGDT0cWTio50B5vo+8/WzU3FxRpjJLGwH0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2SPR01MB0035 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Roll] giving back MPDAO to RFC editor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 06:30:55 -0000 --_000_MN2PR11MB3565D2139143EFF0F43055E3D8BB0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul RPL says 1-127: Not an outright rejection; the node sending the DAO-ACK is willing to act as a parent, but the receiving node is suggested to find and use an alternate parent instead. 127-255: Rejection; the node sending the DAO-ACK is unwilling to act as a parent. Note that the 127 as a rejection is a typo. The intent was that 127 is not = a rejection. We could write an erratum for this I guess so rejection starts= at 128. All the best, Pascal From: Rahul Jadhav > Sent: jeudi 5 septembre 2019 05:44 To: Pascal Thubert (pthubert) >; Routing Over Low power and Lossy networks > Subject: Re: [Roll] giving back MPDAO to RFC editor Thank you Pascal for the changes and pull request. Have merged the changes. I made two minor changes, please check if there are ok: https://github.com/roll-wg/efficient-route-invalidation/commit/8af38e8f44b9= 63987ee6754d644d6ef70409462f If yes, then please use the latest xml from https://github.com/roll-wg/efficient-route-invalidation/blob/master/draft-i= etf-roll-efficient-npdao.xml Thanks, Rahul ________________________________ From: Roll > on behalf = of Ines Robles > Sent: Wednesday, September 4, 2019 10:33 AM To: Pascal Thubert (pthubert) > Cc: roll > Subject: Re: [Roll] giving back MPDAO to RFC editor Hi Pascal, Thank you very much for your hard work. Could you please convert the draft-ietf-roll-efficient-npdao-16.xml to txt = [https://xml2rfc.tools.ietf.org/] and put them here https://github.com/roll= -wg/efficient-route-invalidation, so people can read the complete document = with the proposed changes, thus we can have a last call. Many thanks again, Ines and Peter. On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) > wrote: Dear all We are holding NP DAO for a change that does not impact the behavior of the= node but improves traceability. I would like to confirm consensus on this change rapidly so we can give the= doc back to RFC editor. The proposed change is as follows: ---------------------------------- diff --git "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll= -efficient-npdao-15.xml" "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\d= raft-ietf-roll-efficient-npdao-16.xml" index 8a0acca..2ed0920 100644 --- "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-effici= ent-npdao-15.xml" +++ "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-effici= ent-npdao-16.xml" @@ -35,7 +35,7 @@ - +

Hello Rahul

 

RPL says

 

     1-127:  Not an outright reje= ction; the node sending the DAO-ACK

         &nbs= p;     is willing to act as a parent, but the receiving= node is

         &nbs= p;     suggested to find and use an alternate parent in= stead.

     127-255:  Rejection; the nod= e sending the DAO-ACK is unwilling to

         &nbs= p;     act as a parent.

 

 

Note that the 127 as a rejection is a typo. The inte= nt was that 127 is not a rejection. We could write an erratum for this I gu= ess so rejection starts at 128.

 

All the best,

 

Pascal

 

From: Rahul Jadhav <nyrahul@outlook.com>
Sent: jeudi 5 septembre 2019 05:44
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Routing Over Low power and Lossy networks &= lt;roll@ietf.org>
Subject: Re: [Roll] giving back MPDAO to RFC editor

 

Thank y= ou Pascal for the changes and pull request.

Have me= rged the changes.

I made = two minor changes, please check if there are ok: 

&n= bsp;

If yes,= then please use the latest xml from 

&n= bsp;

Thanks,=

Rahul

From: Roll <roll-bounces@ietf.org> on behalf o= f Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org>
Sent: Wednesday, September 4, 2019 10:33 AM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] giving back MPDAO to RFC editor

 

 

On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthub= ert) <pthubert@cisco.com> w= rote:

Dear all

 

We are holding NP DAO for a change that does not im= pact the behavior of the node but improves traceability.

I would like to confirm consensus on this change ra= pidly so we can give the doc back to RFC editor.

 

The proposed change is as follows:

 

----------------------------------

 

diff --git "a/C:\\Users\\pthubert\\Dropbox\\IETF\\do= c\\rpi\\draft-ietf-roll-efficient-npdao-15.xml" "b/C:\\Users\\pth= ubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"= ;

index 8a0acca..2ed0920 100644

--- "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\= \draft-ietf-roll-efficient-npdao-15.xml"

+++ "b/C:\\Users\\pthubert\\Dropbox\\IET= F\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"=

@@ -35,7 +35,7 @@

<?rfc subcompact=3D"yes" ?>

<!-- keep one blank line between list items -->

<!-- end of list of popular I-D processing instruction= s -->

-<rfc category=3D"std" docName=3D"draft= -ietf-roll-efficient-npdao-15" ipr=3D"trust200902">

+<rfc category=3D"std" docName=3D"d= raft-ietf-roll-efficient-npdao-16" ipr=3D"trust200902">

   <!-- category values: std, bcp, info, exp= , and historic

      ipr values: full3667, noMo= dification3667, noDerivatives3667

      you can add the attributes= updates=3D"NNNN" and obsoletes=3D"NNNN"

@@ -582,11 +582,12 @@

 

         &nb= sp;   <t>

         &nb= sp;       This document specifies a change in= the Transit Information Option to

-         &n= bsp;      contain the "Invalidate previous ro= ute" (I) flag. This I-flag signals

+        &nbs= p;       contain the "Invalidate previou= s route" (I) flag. This 'I' flag signals

         &nb= sp;       the common ancestor node to generat= e a DCO on behalf of the

-         &n= bsp;      target node. The I-flag is carried in th= e Transit Information

+        &nbs= p;       target node with a RPL Status of 130= indicating that the address

+        &nbs= p;       has moved. The 'I' flag is carried i= n the Transit Information

         &nb= sp;       Option which augments the reachabil= ity information for a given

-         &n= bsp;      set of RPL Target(s). Transit Informatio= n Option with I-flag

+        &nbs= p;       set of RPL Target(s). Transit Inform= ation Option with 'I' flag

         &nb= sp;       set should be carried in the DAO me= ssage when route

         &nb= sp;       invalidation is sought for the corr= esponding target(s).

         &nb= sp;   </t>

@@ -615,8 +616,8 @@

         &nb= sp;   </t>

         &nb= sp;   <t>

         &nb= sp;       The common ancestor node SHOULD gen= erate a DCO message in

-         &n= bsp;      response to this I-flag when it sees tha= t the routing

-         &n= bsp;      adjacencies have changed for the target.= The I-flag is

+        &nbs= p;       response to this 'I' flag when it se= es that the routing

+        &nbs= p;       adjacencies have changed for the tar= get. The 'I' flag is

         &nb= sp;       intended to give the target node co= ntrol over its own route

         &nb= sp;       invalidation, serving as a signal t= o request DCO generation.

         &nb= sp;   </t>

@@ -638,7 +639,7 @@

0         &n= bsp;         1   &nb= sp;            =    2          &= nbsp;        3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1

+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

-| RPLInstanceID |K|D|   Flags   |&nb= sp;  Reserved    | DCOSequence   |

+| RPLInstanceID |K|D|   Flags   = |  RPL  Status  | DCOSequence   |

+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

|         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

+        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    +

@@ -683,8 +684,15 @@

         &nb= sp;       the sender and MUST be ignored by t= he receiver.

         &nb= sp;   </t>

         &nb= sp;   <t>

-         &n= bsp;      Reserved: 8-bit unused field. The field = MUST be initialized to

-         &n= bsp;      zero by the sender and MUST be ignored b= y the receiver.

+        &nbs= p;       RPL Status: The RPL Status as define= d in section 6.5.1 of <xref

+        &nbs= p;       target=3D"RFC6550"/>.

+        &nbs= p;       Indicative of the reason why the DCO= happened, the RPL Status

+        &nbs= p;       MUST NOT be changed as the DCO is pr= opagated down the route

+        &nbs= p;       being invalidated.=

+        &nbs= p;       This value is informative and does n= ot affect the behavior of

+        &nbs= p;       the receiver. In particular, unknown= values are ignored by the

+        &nbs= p;       receiver.

+        &nbs= p;       Only Rejection Codes (value above 12= 8) are expected in a DCO.

         &nb= sp;   </t>

         &nb= sp;   <t>

         &nb= sp;       DCOSequence: 8-bit field incremente= d at each unique DCO message

@@ -759,7 +767,7 @@

0         &n= bsp;         1   &nb= sp;            =    2          &= nbsp;        3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1

+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

-| RPLInstanceID |D|   Flags   &= nbsp; |  DCOSequence  |    Status   = ;  |

+| RPLInstanceID |D|   Flags  &nb= sp;  |  DCOSequence  | DCO-ACK Status|

+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

|         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

+        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    +

@@ -788,8 +796,10 @@

         &nb= sp;           copied from= the DCOSequence received in the DCO message.

         &nb= sp;       </t>

         &nb= sp;       <t>

-         &n= bsp;          Status: Indicate= s the completion. Status 0 is defined as

-         &n= bsp;          unqualified acce= ptance in this specification. Status 1 is

+        &nbs= p;           DCO-ACK Stat= us: Indicates the completion. A value of 0 is

+        &nbs= p;           defined as

+        &nbs= p;           unqualified = acceptance in this specification. A value of 1

+        &nbs= p;           is

         &nb= sp;           defined as = "No routing-entry for the Target found". The

         &nb= sp;           remaining s= tatus values are reserved as rejection codes.

         &nb= sp;       </t>

@@ -910,7 +920,7 @@

         &nb= sp;           nodes will = generate their respective DAOs to update their

         &nb= sp;           paths, and = the previous route invalidation for those nodes

         &nb= sp;           should work= in the similar manner described for switching

-         &n= bsp;          node. The depend= ent node may set the I-flag in the Transit

+        &nbs= p;           node. The de= pendent node may set the 'I' flag in the Transit

         &nb= sp;           Information= Option as part of regular DAO so as to

         &nb= sp;           request inv= alidation of previous route from the common

         &nb= sp;           ancestor no= de.

@@ -920,7 +930,7 @@

         &nb= sp;           of their pa= rents in turn have decided to switch their

         &nb= sp;           parent. Thu= s for route invalidation the dependent nodes may

         &nb= sp;           choose to a= lways set the 'I' flag in all its DAO message's

-          &= nbsp;         Transit Informat= ion Option. Note that setting the I-flag is

+        &nbs= p;           Transit Info= rmation Option. Note that setting the 'I' flag is

         &nb= sp;           not counter= productive even if there is no previous

         &nb= sp;           route to be= invalidated.

         &nb= sp;       </t>

@@ -1103,7 +1113,7 @@

 

         <t>= ;

         &nb= sp;   IANA is requested to allocate bit 1 from the Transit Inform= ation

-          &= nbsp; Option Flags registry for the I-flag (<xref target=3D"tr= ansit_opt_changes"/>)

+        &nbs= p;   Option Flags registry for the 'I' flag (<xref target=3D&q= uot;transit_opt_changes"/>)

         </t&g= t;

         <sect= ion title=3D"New Registry for the Destination Cleanup Object (DCO) Fla= gs">

         &nb= sp;   <t>

@@ -1210,22 +1220,29 @@

         &nb= sp;   This document introduces the ability for a common ancestor = node to

         &nb= sp;   invalidate a route on behalf of the target node. The common=

         &nb= sp;   ancestor node could be directed to do so by the target node= using

-         &n= bsp;  the I-flag in DCO's Transit Information Option. However, the com= mon

+        &nbs= p;   the 'I' flag in DCO's Transit Information Option. However, t= he common

         &nb= sp;   ancestor node is in a position to unilaterally initiate the= route

         &nb= sp;   invalidation since it possesses all the required state info= rmation,

         &nb= sp;   namely, the Target address and the corresponding Path Seque= nce..

         &nb= sp;   Thus a rogue common ancestor node could initiate such an

         &nb= sp;  invalidation and impact the traffic to the target node.

         </t&g= t;

+        <t>= The DCO carries a RPL Status value, which is informative. New Status

+        &nbs= p;   values may be created over time and a node will ignore an un= known

+        &nbs= p;   Status value. Which makes it so that the RPL Status field ma= y be

+        &nbs= p;   used as a cover channel. But the channel only works once sin= ce the

+        &nbs= p;   message destroys its own medium, that is the existing route = that it

+        &nbs= p;   is removing.

+        </t>= ;

         <t>= ;

-         &n= bsp;  This document also introduces an I-flag which is set by the targ= et

+        &nbs= p;   This document also introduces an 'I' flag which is set by th= e target

         &nb= sp;   node and used by the ancestor node to initiate a DCO if the=

         &nb= sp;   ancestor sees an update in the route adjacency. However,

         &nb= sp;   this flag could be spoofed by a malicious 6LR in the path a= nd can

         &nb= sp;   cause invalidation of an existing active path. Note that in= validation

         &nb= sp;   will happen only if the other conditions such as Path Seque= nce

         &nb= sp;   condition is also met. Having said that, such a malicious 6= LR may

-         &n= bsp;  spoof a DAO on behalf of the (sub) child with the I-flag set and=

+        &nbs= p;   spoof a DAO on behalf of the (sub) child with the 'I' flag s= et and

         &nb= sp;   can cause route invalidation on behalf of the (sub) child n= ode..

         &nb= sp;   Note that, using existing mechanisms offered by <xref

         &nb= sp;       target=3D"RFC6550"/>, = a malicious 6LR might also spoof a DAO with

 

 

Chairs, could we please last call or whatever so we= can move on?

 

Many thanks!

 

Pascal

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--_000_MN2PR11MB3565D2139143EFF0F43055E3D8BB0MN2PR11MB3565namp_--