Re: [Roll] giving back MPDAO to RFC editor

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 05 September 2019 07:09 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 6A10112006F for <roll@ietfa.amsl.com>; Thu, 5 Sep 2019 00:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=PzyIM5BJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nipVQs0w
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 JEiMRuhExHV4 for <roll@ietfa.amsl.com>; Thu, 5 Sep 2019 00:09:06 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E501200A1 for <roll@ietf.org>; Thu, 5 Sep 2019 00:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15230; q=dns/txt; s=iport; t=1567667346; x=1568876946; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jqAYaYBp2YRpqUziCJV6yVeCEOjDvvpsg0E6qgx8Bxc=; b=PzyIM5BJn/n0bwHmMYoSbpGQ4rq3yQOqxlM4kGa8H0CeliSqX0mXrDHx MMsbIHz/0lcl0xkRxk36EPlrrOgFibEd8Vh4W1xyzuFcntlM0qZJP0dt9 2mb68oZdSGbu8Th9jv1J2WGqQNeKFpHDTk3VccSJ8VhEHG5Yt3cOLNXb8 A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0L1TaxY5+ESTI1RRsAuc/1P/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAAAZtHBd/5JdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FFJCwDbVYgBAsqh2gDinVNgg9+lm6BQoEQA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBhD8CgjUjOBMCAwgBAQQBAQECAQYEbYUuDIVKAQEBAQMBARAVEwY?= =?us-ascii?q?BASUHAgoLBAIBCBEEAQEBHhAnCx0IAQEEEwgagnsEAoFqAx0BAgyfOAKBOIh?= =?us-ascii?q?hgXIzgnwBAQVrRwGDYRiCFgMGgTSFAIZ4GIFAP4ERRlGBRgcuPoJhAQECgSc?= =?us-ascii?q?cHoM7giaMRQsEn1cKgh+Gd44IgjSHOYQeimWPMYVXbJBbAgQCBAUCDgEBBYF?= =?us-ascii?q?nIQ2BS3AVGiGCbIJCDBeDT4UUhT9zAYEojyUBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,469,1559520000"; d="scan'208";a="320134483"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Sep 2019 07:09:04 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x85794pP016639 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 5 Sep 2019 07:09:04 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 02:09:04 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 02:09:03 -0500
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 5 Sep 2019 02:09:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NBwtl8Gbmt15q13/l9yJEolkmQeRyKwvd0x9SKWuiOgNqcOAJ8FaJpa5YmFYODg0+vl+873JU4aIZHxhMXMpjxDPQKZClONy3NBoFIT+pPob3tC9+7DfGknHdVUbkYSGQKmYo87JOl3ft7BvC9NNuZOdLaXhmfRqBzsvak7vFy1aJybqda+1uT2Ogfdy57kwxd024+BbSEV2cTRm6yip7RK9Yog6OoBjiGOhQ/uJCvEXQIMDZB4l9AcuThqTSx201feTvMQJ9xEqm7IjsUK/vdSNDXVuLYCla4L1rjJsDS9SGHYyGgXjQad4h5itisIW1xKzZZgBPUJpy/+p6Uh2dg==
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=EiYFsBY2KcwKBqtf9WQPVytdhLiIWY1bWuXOXU/4JTY=; b=fA1U3HMFiO8pszUeke/VKpXzee6Op6BxFnnkvA8Y+3pIJgMuZYIeaPBfHVBe0jbuhj96MbZ5QcAm73OR2Wdqmrgdk7gdZ20tyVzQNyCVUAxTpLZwrRU4+MZPefV1HxSL6c1ixFDZrwyDn9tU4jNrkYbmf/w3gDfHWTnRFvtvj5tRM4c3nTk/HxfpXANY+vObnORhHMaeI3cEkkRnQiUguL8+/Rm1ELmpWblg5diCCoCdOeytTXVob120pwoJmNkDFquiZQ7Xj3wbJRCiHxo/X7CFIxFZY/0rRZi5/9EqNV9dvFvNwz/3v/9mksoPEoT9WVEVKCdOT0QLNCj9Wfky9w==
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=EiYFsBY2KcwKBqtf9WQPVytdhLiIWY1bWuXOXU/4JTY=; b=nipVQs0w1lgsJV/OhoCHsMeMTOV1BZac+Vi4hXhUrHwL/B3y5FoS40SFeeXba9CTgeY5qv6eqlnC+9SfHhJMcnMPm8WtksJNGMo+lJmbjLazwulyn0fhsNvC7AkBVUuw7sV7HETKFymBfjbsBWWHiZC44uD0mjRF2LLkx3LzgVM=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4095.namprd11.prod.outlook.com (20.179.150.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Thu, 5 Sep 2019 07:09: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 07:09:02 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] giving back MPDAO to RFC editor
Thread-Index: AdVjB/JIrm5BouKOTamY5+QcgzHTjqccbzTnpxsrrVCxycMngP///SVQ
Date: Thu, 5 Sep 2019 07:08:52 +0000
Deferred-Delivery: Thu, 5 Sep 2019 07:08:40 +0000
Message-ID: <MN2PR11MB35651E5CC22976AE44928CB6D8BB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565DAEEF4DD78D732EDE17DD8B80@MN2PR11MB3565.namprd11.prod.outlook.com> <CAP+sJUc+UMsqDQvyc1kaM8zNmq43jB9zNRXZ7eijyB9XjcomiQ@mail.gmail.com> <BM1PR01MB26126BE7BC1F809C34E0B5DBA9BB0@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM> <MN2PR11MB3565D2139143EFF0F43055E3D8BB0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAO0Djp1Vb6DTeJGix_93Ee_jqaaZRkJDurb_6OvWxZcKi=xe_w@mail.gmail.com>
In-Reply-To: <CAO0Djp1Vb6DTeJGix_93Ee_jqaaZRkJDurb_6OvWxZcKi=xe_w@mail.gmail.com>
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: 2708b557-b7f9-43a5-7a45-08d731cfee4e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4095;
x-ms-traffictypediagnostic: MN2PR11MB4095:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <MN2PR11MB40955627D2AA631152DE6CE0D8BB0@MN2PR11MB4095.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 015114592F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(396003)(366004)(376002)(39860400002)(13464003)(189003)(199004)(46003)(11346002)(446003)(316002)(52536014)(5660300002)(6116002)(71200400001)(71190400001)(6436002)(6916009)(186003)(14444005)(256004)(8936002)(486006)(476003)(6666004)(229853002)(25786009)(478600001)(55016002)(99286004)(9686003)(966005)(2906002)(6306002)(86362001)(53946003)(14454004)(6246003)(33656002)(76116006)(81156014)(81166006)(76176011)(7696005)(102836004)(8676002)(74316002)(53936002)(66476007)(66556008)(64756008)(66446008)(66946007)(6506007)(53546011)(7736002)(305945005)(19607625011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4095; 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: ywUm5hjwyKqcbTBIShJ0iZC5gzb6MW8aaDoJML+C1cha7SiMCMfC0/QU0Dz0fn2yOI1Z8Yp1qH1R0TZFXVXFobBFFoFSn3z+s3pI30jPPXCKHJ6UuUjwal7mVxJTRn3YwpkwtUr/AzHeH/zgIn734G+dAbjyVW+HU+Lfw/QnarqOVQwwZqlytahLoDTCWxIiIf50oUBUZixanjK8fSzloXaRBAO/th37qH9rKT8Ci/kxpvemaBKtU5b5yx0WIR76n1gDWtnvdQr0NbD6Hjlk6fs2R6Zme9alTjtPbKgiQtaFYOTj0QORU5IPpbo1nTg2Kg7lqDgkCJp5aD1f/Dork3pt8HFGTxEYEKbtWrrAzSw/85A1v8GSHsD1vFKk9ny5z/q+3/S7dcRBAv1Crxq3gYMZ5EjZWKFjxmULo+1kqx4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2708b557-b7f9-43a5-7a45-08d731cfee4e
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 07:09:02.1556 (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: IEsi8Kbvg5klZfXy8ILkFGfABfJAKokiynN2IvoqusIpuEDLHeJfuu81IBh3twBKqxzQ4AiNZ1+lLbdnG4Z3UQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4095
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mssgbLUahUa6TVRMEXh1tTDpIpE>
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 <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: Thu, 05 Sep 2019 07:09:11 -0000

Cool. 

I created a pull request, also fixing the area tag. Seems you did too, so now we are conflicting : ) 
I'll let you handle it with the change that you prefer.

All the best,

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
> Sent: jeudi 5 septembre 2019 08:56
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] giving back MPDAO to RFC editor
> 
> The erratum seems to have been reported long back.
> Final updates: https://github.com/roll-wg/efficient-route-
> invalidation/commit/9fff6e6051c2a2560bddd3f5097bf19149edd52a
> 
> On Thu, 5 Sep 2019 at 12:01, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> >
> > 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 <nyrahul@outlook.com>
> > Sent: jeudi 5 septembre 2019 05:44
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; Routing Over Low
> > power and Lossy networks <roll@ietf.org>
> > 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/8af38e8
> > f44b963987ee6754d644d6ef70409462f
> >
> >
> >
> > If yes, then please use the latest xml from
> >
> > https://github.com/roll-wg/efficient-route-invalidation/blob/master/dr
> > aft-ietf-roll-efficient-npdao.xml
> >
> >
> >
> > Thanks,
> >
> > Rahul
> >
> > ________________________________
> >
> > From: Roll <roll-bounces@ietf.org> on behalf of Ines Robles
> > <mariainesrobles=40googlemail.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
> >
> >
> >
> > 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)
> <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
> > https://www.ietf.org/mailman/listinfo/roll
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll