Re: [Roll] Last call to draft-ietf-roll-efficient-npdao-16

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 04 September 2019 17: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 EA27A120ADB for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 10:38:03 -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=OIQnYwO6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B8kUHd+q
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 ctlkzt9Bifz7 for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 10:38:00 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A0D120ABB for <roll@ietf.org>; Wed, 4 Sep 2019 10:37:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75357; q=dns/txt; s=iport; t=1567618679; x=1568828279; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=duDIiaHiEyrc7U6RCUvVMcB2qxLC2TYVTBnJpXvjxa0=; b=OIQnYwO6FgRfmTcZ/gFiOuNk5rpX1ObDbh9U8GuJPzc3Wj+vt10Mxudy 7KazdzZWhAGSSQUYjbrXVp4Scqc+iq0tm/lWW7nK8kljL3l3vC7dh6xSW rHl8cXnQ5C9xv++quKr1cwTNkgGihYxlerb6S6ZZxpdoLGbcmeW2BLBKY c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AX1O38xQomkozv5JnTZsAToTfsdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAAm9m9d/4sNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EWAS4kLANtD0cgBAsqCoQXg0cDinWCXH6WboFCgRADUAQ?= =?us-ascii?q?JAQEBDAEBGAEOBgIBAYQ/AheCGyM4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQE?= =?us-ascii?q?BAwEBEAsGBBkBASUHAgoPAgEIEQQBASEBBgMCAgIlCxQJCAIEEyKCewQBAYE?= =?us-ascii?q?dTQMdAQIBC6AzAoE4iGFzfzOCfAEBBWuBXIJLGIIWAwaBNIt4GIFAP4ERJx9?= =?us-ascii?q?RgUY1PoJhAQECgSccJA8QBgmCVTKCJowvFQ+CXoUeiRGOSAqCH4Z2hx+GTBu?= =?us-ascii?q?CNIc2iQuFdo8vhkGQVgIEAgQFAg4BAQWBZyENgUtwFRohKgGCQYJCDBeDT4U?= =?us-ascii?q?UhT9zAYEojRUBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,467,1559520000"; d="scan'208,217";a="624109801"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Sep 2019 17:37:50 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x84HboCX024532 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 4 Sep 2019 17:37:50 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 12:37:49 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 12:37:48 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 4 Sep 2019 12:37:48 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kinr1aVn2BNmHJouyBet+eol6GuqAM7MhK4D5EpPfTjzhQES/t/ieyv8znb+N5isSlFkUgkfdzslBA7cMmccGkxNWIt6aauI9aHkZsTIGQPgg5VxOC5/bCqZ6MPA6lnDxcZHGSjQY5b9Ei2FzESrfZds9ktr313iJst8CuJvpT8xRQq5bGMN2sW85eh3SD+ca7o26yx7W2W4FI4quZ8CpnMDlG3eTXg06odvLZCRqEyB5IKoi1U6uK/Lv8PNm4Xh44FViipzMeUlNJFHI+RuikX/MDh3iijVLvbWneKfUIZU9wXjFlBom51v78jJDeMhb4uRevwZpuSd8nJiJxWNvg==
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=duDIiaHiEyrc7U6RCUvVMcB2qxLC2TYVTBnJpXvjxa0=; b=i6vWP8YVWXXRymHY5UFgQBGRFR9ezl0SMebMZbc7p5kg4ye2NOwhylvigIsjJMbwPlzGTKG3SeSDf6tb/9b0ttH5FcHO4tDUC767Dppgm5Z43z/5sk8GV1/x+3sj4m07J7wDwHL/zuCBlVq+Sqd3S9Es6wxZtvkaemu7A2dltmbk4xSe9clKtT8T3CRDntnAMCvuCbaUEGYvevL+QV+Ki1vp+oYR+veU2ELAAb0KCA3qKzbgTI/CQG7QPMM0eASRuaZWeBMgSD+r05KnDNTbxXVrruqM4rusR9pg2qReBPuzXHe4u7aV3Nlp79FrNmiz99wBHPXkTr9s/NPt38+whw==
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=duDIiaHiEyrc7U6RCUvVMcB2qxLC2TYVTBnJpXvjxa0=; b=B8kUHd+qfvYgQPH0HoGT4FFH2CXtykrNBSF9WD44MlH7+ioytDisS4U+UCRkhfFHu2t9sHMaypU2XJcS9VZUu3VXtZ+31rXIacxg73Bakb66IyMYMie5sThmTLAunDNYBqFKTdqNLCi+a+33CyDoGxs+c/86uYdHdL/D1zeHcuM=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3757.namprd11.prod.outlook.com (20.178.253.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.15; Wed, 4 Sep 2019 17:37:47 +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; Wed, 4 Sep 2019 17:37:47 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Last call to draft-ietf-roll-efficient-npdao-16
Thread-Index: AQHVYzuxoNViEaVzvEWym+ayJ9AKJKcbyHcA
Date: Wed, 4 Sep 2019 17:37:47 +0000
Message-ID: <2AAEF50F-4E23-45C3-95F1-0873CA692B48@cisco.com>
References: <MN2PR11MB3565DAEEF4DD78D732EDE17DD8B80@MN2PR11MB3565.namprd11.prod.outlook.com>, <CAP+sJUeEWC-bhw2U0t82-45ha3vOEcuqiD9U4Hmc-xR=y6PM6w@mail.gmail.com>, <BM1PR01MB2612F1D77693AC23B903C420A9B80@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB2612F1D77693AC23B903C420A9B80@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [91.69.164.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b6e81a1e-d329-4865-08ac-08d7315e99e2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3757;
x-ms-traffictypediagnostic: MN2PR11MB3757:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB3757C403475A21C644554AF6D8B80@MN2PR11MB3757.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0150F3F97D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(316002)(966005)(2906002)(256004)(86362001)(606006)(14454004)(99286004)(14444005)(71190400001)(71200400001)(66574012)(64756008)(66556008)(45080400002)(66476007)(76116006)(478600001)(66946007)(91956017)(66446008)(76176011)(53546011)(6506007)(6486002)(25786009)(8676002)(26005)(102836004)(5660300002)(186003)(5070765005)(229853002)(8936002)(81166006)(81156014)(6916009)(6306002)(66066001)(6246003)(54896002)(6436002)(236005)(6512007)(7736002)(53936002)(446003)(11346002)(36756003)(33656002)(2616005)(476003)(486006)(3846002)(53946003)(6116002)(579004)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3757; 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: S8rpFGmrAw9IlVHyZKQPD4+JuG9eU9Pum1hbOhbUERbYXdo0QBFpU4Xskyj4vO+CHpA2Mbi1wzO4Xnlj8tGhZkWXHa39aDGS3rdvT3LrHa+KKrgjmgKf5MYoUydNDfY2KSn6tFvbNF1QwVTP4Fwog78yA4HHAAqevduuyRS0lHHXUK3DxP1dR9E3Szi3KKt5jRwfSduQeVAWN2zZnHWebp7qYRHOFWoYJZyOvJT0uJYO1ffjuYx55DV9NH+tu9EHROk+eNIbX4EtGpKrnqXNVXIEzAMbeYtU/8ukvp1GGB63fmQdB8Ef+dT1CSPY4MkyAvhik6zQ10y4keUPrDh2hjkVsX30lzC4gKjPGetinuW5YFrZ5ef0NjDQvBqglblyikzpMsYd70/37gida1eNz91w0fNpqaVosMmsyWgd6q8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2AAEF50F4E2345C395F10873CA692B48ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b6e81a1e-d329-4865-08ac-08d7315e99e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2019 17:37:47.3309 (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: Bx3xRwm7qhA2fqQ0u27WLfXDN6J3F+2Sb6VgpHdwEZ78AERpjAUWu/5TXbVtRHmyF0GrKCBy3MNvTbZ189n3FA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3757
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/zSSlE-E7LF6xvz8b_fQS8ASX9wo>
Subject: Re: [Roll] Last call to draft-ietf-roll-efficient-npdao-16
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 17:38:04 -0000

Well since RPL did not create a registry we are on our own. My suggestion is to fix this in the RUL draft, see the IANA section there. The code 130 is consistent with it.

Regards,

Pascal

Le 4 sept. 2019 à 18:13, Rahul Jadhav <nyrahul@outlook.com<mailto:nyrahul@outlook.com>> a écrit :

Hi Pascal,

The new text contains "RPL status code of 130 indicating that the address is moved". It has no reference and no IANA consideration. Is it ok to simply state this without explicit IANA consideration? Maybe I am just not aware of such procedural aspects of status code allocation, but how would a future work avoid using this value?

Regards,
Rahul

________________________________
From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Ines Robles <mariainesrobles=40googlemail.com@dmarc.ietf.org<mailto:mariainesrobles=40googlemail.com@dmarc.ietf.org>>
Sent: Wednesday, September 4, 2019 2:02 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] Last call to draft-ietf-roll-efficient-npdao-16

Dear all,

This is a last call for the modified NPDAO document (version 16) that you can find here

https://github.com/pthubert/efficient-route-invalidation/blob/master/draft-ietf-roll-efficient-npdao.txt

This call is open until 23th September. Please let us know your opinion.

Thank you very much in advance,

Ines and Peter.

On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> 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\\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\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"

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

<?rfc subcompact="yes" ?>

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

<!-- end of list of popular I-D processing instructions -->

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

+<rfc category="std" docName="draft-ietf-roll-efficient-npdao-16" ipr="trust200902">

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

      ipr values: full3667, noModification3667, noDerivatives3667

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

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



             <t>

                 This document specifies a change in the Transit Information Option to

-                contain the "Invalidate previous route" (I) flag. This I-flag signals

+                contain the "Invalidate previous route" (I) flag. This 'I' flag signals

                 the common ancestor node to generate a DCO on behalf of the

-                target node. The I-flag is carried in the Transit Information

+                target node with a RPL Status of 130 indicating that the address

+                has moved. The 'I' flag is carried in the Transit Information

                 Option which augments the reachability information for a given

-                set of RPL Target(s). Transit Information Option with I-flag

+                set of RPL Target(s). Transit Information Option with 'I' flag

                 set should be carried in the DAO message when route

                 invalidation is sought for the corresponding target(s).

             </t>

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

             </t>

             <t>

                 The common ancestor node SHOULD generate a DCO message in

-                response to this I-flag when it sees that the routing

-                adjacencies have changed for the target. The I-flag is

+                response to this 'I' flag when it sees that the routing

+                adjacencies have changed for the target. The 'I' flag is

                 intended to give the target node control over its own route

                 invalidation, serving as a signal to request DCO generation.

             </t>

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

0                   1                   2                   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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-| RPLInstanceID |K|D|   Flags   |   Reserved    | DCOSequence   |

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

+                                                               +

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

                 the sender and MUST be ignored by the receiver.

             </t>

             <t>

-                Reserved: 8-bit unused field. The field MUST be initialized to

-                zero by the sender and MUST be ignored by the receiver.

+                RPL Status: The RPL Status as defined in section 6.5.1 of <xref

+                target="RFC6550"/>.

+                Indicative of the reason why the DCO happened, the RPL Status

+                MUST NOT be changed as the DCO is propagated down the route

+                being invalidated.

+                This value is informative and does not affect the behavior of

+                the receiver. In particular, unknown values are ignored by the

+                receiver.

+                Only Rejection Codes (value above 128) are expected in a DCO.

             </t>

             <t>

                 DCOSequence: 8-bit field incremented at each unique DCO message

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

0                   1                   2                   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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-| RPLInstanceID |D|   Flags     |  DCOSequence  |    Status     |

+| RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

+                                                               +

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

                     copied from the DCOSequence received in the DCO message.

                 </t>

                 <t>

-                    Status: Indicates the completion. Status 0 is defined as

-                    unqualified acceptance in this specification. Status 1 is

+                    DCO-ACK Status: Indicates the completion. A value of 0 is

+                    defined as

+                    unqualified acceptance in this specification. A value of 1

+                    is

                     defined as "No routing-entry for the Target found". The

                     remaining status values are reserved as rejection codes.

                 </t>

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

                     nodes will generate their respective DAOs to update their

                     paths, and the previous route invalidation for those nodes

                     should work in the similar manner described for switching

-                    node. The dependent node may set the I-flag in the Transit

+                    node. The dependent node may set the 'I' flag in the Transit

                     Information Option as part of regular DAO so as to

                     request invalidation of previous route from the common

                     ancestor node.

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

                     of their parents in turn have decided to switch their

                     parent. Thus for route invalidation the dependent nodes may

                     choose to always set the 'I' flag in all its DAO message's

-                    Transit Information Option. Note that setting the I-flag is

+                    Transit Information Option. Note that setting the 'I' flag is

                     not counterproductive even if there is no previous

                     route to be invalidated.

                 </t>

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



         <t>

             IANA is requested to allocate bit 1 from the Transit Information

-            Option Flags registry for the I-flag (<xref target="transit_opt_changes"/>)

+            Option Flags registry for the 'I' flag (<xref target="transit_opt_changes"/>)

         </t>

         <section title="New Registry for the Destination Cleanup Object (DCO) Flags">

             <t>

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

             This document introduces the ability for a common ancestor node to

             invalidate a route on behalf of the target node. The common

             ancestor node could be directed to do so by the target node using

-            the I-flag in DCO's Transit Information Option. However, the common

+            the 'I' flag in DCO's Transit Information Option. However, the common

             ancestor node is in a position to unilaterally initiate the route

             invalidation since it possesses all the required state information,

             namely, the Target address and the corresponding Path Sequence..

             Thus a rogue common ancestor node could initiate such an

            invalidation and impact the traffic to the target node.

         </t>

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

+            values may be created over time and a node will ignore an unknown

+            Status value. Which makes it so that the RPL Status field may be

+            used as a cover channel. But the channel only works once since the

+            message destroys its own medium, that is the existing route that it

+            is removing.

+        </t>

         <t>

-            This document also introduces an I-flag which is set by the target

+            This document also introduces an 'I' flag which is set by the target

             node and used by the ancestor node to initiate a DCO if the

             ancestor sees an update in the route adjacency. However,

             this flag could be spoofed by a malicious 6LR in the path and can

             cause invalidation of an existing active path. Note that invalidation

             will happen only if the other conditions such as Path Sequence

             condition is also met. Having said that, such a malicious 6LR may

-            spoof a DAO on behalf of the (sub) child with the I-flag set and

+            spoof a DAO on behalf of the (sub) child with the 'I' flag set and

             can cause route invalidation on behalf of the (sub) child node..

             Note that, using existing mechanisms offered by <xref

                 target="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<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll