Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 30 October 2019 07: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 714DD120880; Wed, 30 Oct 2019 00:38:47 -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=gFOkU1ZV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DMb85SQB
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 nXRO1CyQXjmd; Wed, 30 Oct 2019 00:38:44 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756C4120878; Wed, 30 Oct 2019 00:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18738; q=dns/txt; s=iport; t=1572421124; x=1573630724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XHQcB59SJKqY0NcoXLIQVDle6cFh9s83nhaxy/N98NA=; b=gFOkU1ZVGTjdsISfOyH/Z2a2K5iX2Qk3VGwzeu1wiSkQk2xorFix5WpH rTIYjEbCkaaItuddPb+VgeRV2ye6qvxVudiDm5fOF9JvxW7jVNIF+sXc6 sou/POanAJcCRROnhodLe6n4DyRoCA6yamTZUBWI7thUn7homD8Nkb3wS s=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ad4olRh8+j+oT3P9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAAB/Pbld/4oNJK1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF9gUspJwVsWCAECxcThCiDRgOKd4Jef4hWjha?= =?us-ascii?q?BQoEQA1QJAQEBDAEBIwoCAQGEQAIXg0ckOBMCAwkBAQQBAQECAQUEbYU3DIV?= =?us-ascii?q?RAQEBAQMSEQQNDAEBMgUBCwQCAQgRBAEBAwImAgICHxEVCAgCBAENBQgagwG?= =?us-ascii?q?CRgMuAQIMqBICgTiIYHV/M4J+AQEFhRkNC4IXAwaBDiiMERiBQD+BEUaBTkk?= =?us-ascii?q?1PoIbRwEBAgGBJiEZgw4ygiyNBRIvgjeOcI5CQQqCJIcQihKEKII8jAiLGo4?= =?us-ascii?q?/gUCGbIIRjxACBAIEBQIOAQEFgWkigVhwFYMnUBAUgwYMF4EEAQmCQoUUhT9?= =?us-ascii?q?0AQGBJo1EAQE?=
X-IronPort-AV: E=Sophos;i="5.68,246,1569283200"; d="scan'208";a="359882044"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Oct 2019 07:38:42 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x9U7cgAf002902 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2019 07:38:42 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 02:38:42 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 03:38:40 -0400
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 30 Oct 2019 02:38:40 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kiQ1IFl1ewFLxmMZYGljmcaMbJzcDN0mrj792TboPOwqh4wx1GlpFD/NeERFjaDnyy5MOUa6rGeeIA0EGjM80HqqKsnFvRcJRz3mQN9xoI8fheebcypuOtozCOVU/LA9bKTHODEFPdp6SVE5OzQwiL7R5cHVC90jSDsMAN0hwj/W//vk/KwL4BGQLYe4RF1NkZt92YS6UGScEsj7THeEUpTljvbIamxRJjhSPIpbaZVhO/qOPX98fKbYmkDnDJB40nBiG1z0WSG9Y7qdXsCGjxg00DN08Ae8GPNJspy+IFuArrcUPP4fCX69OHOeLE0p4K2laZ3p0zvvHaiOpSrOUQ==
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=XHQcB59SJKqY0NcoXLIQVDle6cFh9s83nhaxy/N98NA=; b=nHdfIkl3uhMqNRJfyKvVFdPf22gILIHKB43V+XaqoLi5QM8jxgH+TNLRkedUnJ3BxFv/dlaDykf3TNc/Q/Xb6CFc5cfxFCq5DiLLk80vZwQ9ak/3cvibqTDk0URpp9K3tw5rv6H1mlEh+ytDXALof/IVGaDe/jAA4+FiU0w5zeefRedotZXJFdR2McrKvyO8CZx3p+MPzdj7AthDl9oDduyooTY9lICMpHvEKJ+7g/zj6jbX951jGIBV5WwxVfJQUOM59LApcG/cs8c83RA+4rhjMlREe4HA+6dUeKluMelCXf4vZgSzye2MLuxJI8FX+NHEwPB1+1BeDenaOfxzBw==
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=XHQcB59SJKqY0NcoXLIQVDle6cFh9s83nhaxy/N98NA=; b=DMb85SQBlZrd1awItjSlgj7OUx66wWhyO3SjsojYkcDeCTwyfM9MJ6dDsh5xtnmeJLdu4YvqmhOBbzdktP86NXNmjc6MBwaj+PxmRq19FMpPINE931BWGKETki8Vd3TiDLlJ0kFmMtoXIny4J0kK9N2zv1N4FwRd+3rSIQoaczg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3822.namprd11.prod.outlook.com (20.178.254.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Wed, 30 Oct 2019 07:38:39 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2387.027; Wed, 30 Oct 2019 07:38:39 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, roll <roll@ietf.org>, Peter van der Stok <consultancy@vanderstok.org>
Thread-Topic: AD Review of draft-ietf-roll-efficient-npdao-16
Thread-Index: AQHVhRpHdCR3gF1qN0eG33Ksa1+m8KdlJ+hggATdowCAARmQUIAFaQ8AgADj+TCAAH+mIIAABu/Q
Date: Wed, 30 Oct 2019 07:38:36 +0000
Deferred-Delivery: Tue, 29 Oct 2019 17:31:57 +0000
Message-ID: <MN2PR11MB3565A5F14E50E8D2022F8768D8600@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAMMESswgX8YynN=tehXDMg+suOiiaCTpnoP9LxoH3orG06_Trw@mail.gmail.com> <MN2PR11MB3565181C2DDC7A3FB7DFCB2FD8690@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsz_MJSC+Sx5hPsTFVufqEGUYjuTJFt7pJs7mut_7nHRxA@mail.gmail.com> <MN2PR11MB3565998D4CD88FF786E892AED8650@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsxBriytQmDELLgOBw4zL8EWKbPKf0i6gztTbuvHDBxWZQ@mail.gmail.com> <MN2PR11MB356591018987E7D4FA6215A6D8610@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB3565A9B9ED26D8701A0DC4BAD8610@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565A9B9ED26D8701A0DC4BAD8610@MN2PR11MB3565.namprd11.prod.outlook.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:1006::153]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cd22b69e-5cf8-4a00-7a28-08d75d0c2e84
x-ms-traffictypediagnostic: MN2PR11MB3822:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB3822F8929D00B60612122389D8600@MN2PR11MB3822.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(51444003)(199004)(189003)(13464003)(2906002)(6506007)(229853002)(46003)(71200400001)(476003)(71190400001)(186003)(66946007)(14444005)(66446008)(66556008)(6116002)(64756008)(102836004)(53546011)(6666004)(6436002)(256004)(486006)(76116006)(8936002)(561944003)(81156014)(81166006)(66476007)(99286004)(8676002)(446003)(11346002)(86362001)(76176011)(33656002)(7696005)(5660300002)(110136005)(54906003)(316002)(30864003)(14454004)(66574012)(52536014)(6306002)(9686003)(4326008)(6246003)(55016002)(2501003)(478600001)(966005)(7736002)(74316002)(305945005)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3822; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: aMtd3YniKiRP2kk4vyhWFwh0i7XVj+rdHjdHdYKAwJryZ4aFwuwRPg2f/j02DNTM4w84EfYs2/O3TUi9rGOKHQFKbEXl7+1OG497fCGWseJtynFJTQSZX4MPWymS61XcUaZBAlfYr+GUGid/t8omg8PaBx8B7LeaovMexbiAeaNDOBw239daq9dj52IQfSETHtJMRAyBZIIqxo3us0pOycsxlbAKg+SMsTOHhnxWPsCyli4ceuw+hYfDib5sUaUgoGbxFrSBOXiz/iQsifpGMnqsq2MydL790sYGAkOpWzI4I3YHHeyeoKxl8m85qfo8R2xXeK9nK5s6Jip8LrO1MSbbKywFJq0PxEfBgrCGZrnzwcX8Wyh/qGK6Iuqw8DAZvC5XlUV9GhlRSwwJOZuwuFgC4hhH2Ux8m4RyIm404jVZlpmAeL3IC2SuFexDyvzXDCz1dOIJNPp0h18aqvFjBG/nhoD6sDByjpwroMN/NDs=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cd22b69e-5cf8-4a00-7a28-08d75d0c2e84
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 07:38:39.5790 (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: R7wqelry3EocOl+V0sxuPpkWjirtVhdJxbWx+Ve6W7aXWPyFVJ7BhAFpueUyXgeCPUA2H8wOvKFOsFz/ELoC5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3822
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/R1wsfj6vVZmJUxVE1pylco3LVi8>
Subject: Re: [Roll] AD Review of 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, 30 Oct 2019 07:38:48 -0000

There was a typo, the proposed text in section 7 reads:

   RPL Status subfields:

   E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
      of 0 indicates success and other values indicate an non-outright-
      rejection as per RFC 6550.

   A:  1-bit flag.  Indicates the type of the status value.

   Status Value:  6-bit unsigned integer.  If the 'A' flag is set this
      field transports a status value defined for IPv6 ND EARO.  When
      the 'A' flag is reset, the status value is defined in a RPL
      extension.


Voila!

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Sent: mardi 29 octobre 2019 18:22
> To: Alvaro Retana <aretana.ietf@gmail.com>om>; draft-ietf-roll-efficient-
> npdao@ietf.org
> Cc: roll-chairs@ietf.org; roll <roll@ietf.org>rg>; Peter van der Stok
> <consultancy@vanderstok.org>
> Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16
> 
> Dear all
> 
> More on the proposal below:
> 
> The proposal is to place more details in the RPL status in the RUL draft and
> make it a normative ref to efficient NPDAO.
> 
> Changes in the efficient NPDAO draft:
> ====================
> 
> - Make the RUL draft a normative reference
> 
> - new description of the status:
> "
>    RPL Status: As defined in [RFC6550] and updated in
>    [I-D.ietf-roll-unaware-leaves].  The root or common parent that
>    generates a DCO is authoritative for setting the status information
>    and the information is unchanged as propagated down the DODAG.  This
>    document does not specify a differentiated action based on the RPL
>    status.
> "
> 
> 
> 
> Changes in the RUL draft:
> ====================
> 
> - In 4.  Updating RFC 6550, add:
> 
> "
>    The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
>    DAO-Ack message is extended to be used in the DCO messages
>    [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
>    to use a RPL status to transport the IPv6 ND status defined for use
>    in the EARO, more in Section 7.
> "
> 
> - Create a section 7 as:
> 
> "
> 7.  Updated RPL Status
> 
>    The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
>    the DAO-Ack message and values are assigned as follows:
> 
>                   +---------+---------------------------+
>                   | Range   | Meaning                   |
>                   +=========+===========================+
>                   | 0       | RFC 6550                  |
>                   +---------+---------------------------+
>                   | 1-127   | Not an outright rejection |
>                   +---------+---------------------------+
>                   | 128-255 | Rejection                 |
>                   +---------+---------------------------+
> 
>                       Table 1: RPL Status per RFC 6550
> 
>    This specification extends the scope of the RPL status to be used in
>    RPL DCO messages.  Furthermore, this specification enables to carry
>    the status values defined for use in the IPv6 ND Extended Address
>    Registration Option (EARO) and listed in table 1 of [RFC8505].  Only
>    EARO status values in the range 0-63 can be transported.  The
>    resulting RPL status is as follows:
> 
>        0
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |E|A|  Value    |
>       +-+-+-+-+-+-+-+-+
> 
>    RPL Status subfields:
> 
>    E:  1-bit flag.  Set to indicate a rejection.  When not set, A value
>       of 0 indicates success.  Other values are non-rejection as per RFC
>       6550.
> 
>    A:  1-bit flag.  Set to indicate the type of the status value.
> 
>    Value:  6-bit unsigned integer.  If the 'E' flag is set this field
>       transports a status value defined for IPv6 ND EARO.  When the 'E'
>       flag is reset, the status value is defined in a RPL extension
> 
>    When building a DCO message upon an IPv6 ND NA or DAC message, the
>    root MUST place the ARO status unchanged in a mapped DCO with the 'A'
>    bit set.  Conversely the 6LR MUST place the ARO status unchanged in
>    the NA(EARO) that is built upon a DCO with the 'A' bit set.
> 
> "
> 
> - Remove section 12.2 since we do not create new status values, we now
> transport the ARO status as defined by ND.
> 
> - Instead, create the missing registries that RFC 6550 did not as "
> 
> 13.2.  New Subregistry for the RPL Non-Rejection Status values
> 
>    This specification creates a new subregistry for the RPL Non-
>    Rejection Status values for use in RPL DAO-ACK and RCO Messages,
>    under the ICMPv6 parameters registry.
> 
>    *  Possible values are 6-bit unsigned integers (0..63).
> 
>    *  Registration procedure is "Standards Action" [RFC8126].
> 
>    *  Initial allocation is as indicated in Table 2:
> 
>             +-------+------------------------+---------------+
>             | Value | Meaning                | Defining Spec |
>             +=======+========================+===============+
>             | 0     | Unqualified acceptance | RFC 6550      |
>             +-------+------------------------+---------------+
> 
>             Table 2: Status values of the RPL DAO-ACK Message
> 
> 13.3.  New Subregistry for the RPL Rejection Status values
> 
>    This specification creates a new subregistry for the RPL Non-
>    Rejection Status values for use in RPL DAO-ACK and RCO Messages,
>    under the ICMPv6 parameters registry.
> 
>    *  Possible values are 6-bit unsigned integers (0..63).
> 
>    *  Registration procedure is "Standards Action" [RFC8126].
> 
>    *  There is no initial allocation
> "
> 
> 
> Fire at will!
> 
> Pascal
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: mardi 29 octobre 2019 10:52
> > To: 'Alvaro Retana' <aretana.ietf@gmail.com>om>;
> > draft-ietf-roll-efficient- npdao@ietf.org
> > Cc: roll-chairs@ietf.org; roll <roll@ietf.org>rg>; Peter van der Stok
> > <consultancy@vanderstok.org>
> > Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16
> >
> > .
> > > >
> > > > It cannot be a convergence because RPL had rules in
> > > > https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the
> > > > status below
> > > > 128 are warning.
> > > > That provision was not really used so far to my best knowledge. So
> > > > we could drop it. We chose not to so far. Could be done though if
> > > > that's your recommendation.
> > >
> > > I think that would be a lot clearer...but that is a decision that
> > > the WG needs to make.
> > >
> > >
> >
> >
> > Maybe we could restructure the RPL Status with the first 2 bits
> > becoming significant as opposed to the first bit only.
> >
> > Today:
> >
> > Bit 0 set  => error
> > Bits 1->7 => status code
> >
> > Proposed change:
> >
> > Bit 0 set  => means error ( 0 is warning or OK) Bit 1 set  =>
> > transporting ARO status (refers to RFC 8505 and updates for definition
> > off the next status) Bits
> > 2->7 => status code | ARO status depending on bit 1
> >
> > >
> > > > > (2) draft-ietf-roll-unaware-leaves doesn't update the allocation
> > > > > guidelines from rfc6550 (§6.5.1) for the Status, which then
> > > > > lands "moved" in the "Rejection" range. IOW, the meaning is
> > > > > changed, but the original meaning of the DAO-ACK Status is not
> updated...
> > > > >
> > > > > [We are not reviewing draft-ietf-roll-unaware-leaves here, so
> > > > > some of these comments can be saved for later. ;-)]
> > > >
> > > > I see: we need to indicate that we update/extend the semantics of
> > > > a the DAO-ACK status.
> > > > Should that be indicated in npdao draft or in unaware leaves,
> > > > where the IANA is done for all?
> > >
> > > If the IANA update is to be done in draft-ietf-roll-unaware-leaves,
> > > then there (that is part of the reason for the Normative dependence
> below).
> >
> >
> > I'm good with that. Considering the stage of this doc, I'd rather not
> > change it too much and do the above in the RUL draft.
> > We can complete the RUL draft quite quickly now,  and ship this
> > useofrplinfo and RUL together.
> >
> > >
> > > > > Needless to say, I don't like this approach.
> > >
> > > To be clear, what I don't like is the fact that message that seem to
> > > be intended for different things (ND, DAO-ACK, DCO) share the same
> > > status information...and that it is not consistently corresponding
> > > (the same values don't mean the same things...)....so while
> > > homogenizing is a good thing, we seem to (currently) only go half way.
> > >
> >
> > This is really helpful, Alvaro.
> > I read the whole answer once before starting to answer and the
> > proposal above is what I found to meet this and the below.
> >
> >
> > > > We are specifying it right now in Efficient-NPDAO. RFC 8505 was
> > > > forward looking to that respect. It had to indicate the ND status
> > > > for that case and that status is "moved".
> > > > - It means the guys was down there but is no more. Which is
> > > > exactly the topic of NPDAA, cleanup a downwards path that leads to
> > > > a location from which the target has moved away.
> > > > - But it could not discuss how RPL translates it back and forth.
> > > > The generic spec for that is unaware-leaves. DCO is a special case
> > > > of RC/status that matches "moved" in RFC 8505.
> > >
> > > Ok...so this piece is also dependent on
> > > draft-ietf-roll-unaware-leaves.  I expect then clear pointers from
> > > draft-ietf-roll- efficient-npdao to it.
> > >
> > >
> >
> > Certainly
> >
> >
> > > > The meaning we wanted to convey is that when propagating down the
> > > > DCO, the status from the parent MUST be repeated unchanged to the
> > children.
> > >
> > > Yes, I understand.
> > >
> > > My question is from the Normative point of view.  The rfc2119
> > > keywords "MUST only be used where it is actually required for
> interoperation".
> > > If informative, then we don't need "MUST NOT"...but if there is a
> > > behavior expectation (or as you wrote above: "be turned into ND
> > > again and in those cases the meaning must be conveyed unmodified"),
> > > then the required behavior should be able to be verified
> > > somehow...and, ideally, the specification should include an
> > > indication of what the behavior should be if the mandatory action is
> > > not met.  We can of course trust that nodes will follow the
> > > specification and will not change the
> > contents of the status...
> > >
> > > So..I would like to see a couple of things:
> > >
> > > (1) A clear indication of whether specific behavior is expected (you
> > > have mentioned it twice in this thread, but the document doesn't
> > > reflect that) or not based on the status.
> >
> > Will do
> >
> > >
> > > (2) Text (maybe in the security considerations) pointing out the
> > > effect of, changing the value in-flight, and how (if possible) to mitigate it.
> >
> > Same here. Note that I do not have a mitigation in mind right now.
> >
> >
> > >
> > >
> > > > Suggestion to reword from the perspective of the intermediate router.
> > > >
> > > > > (2) If only values > 128 are expected, then what should a
> > > > > receiver do if a value < 128 is received? Should the DCO not be
> > > > > propagated
> > further?
> > > >
> > > > Yes, the DCO should be propagated and as done today, it causes the
> > > > destruction of the path regardless of the value of the status,
> > > > even a warning <128.
> > > > Should we change that so a warning is propagated but the route is
> > > > conserved or something? There is no known usage of that today,
> > > > does that protect the future better?
> > >
> > > Going back to the text, which reads: "Only Rejection Codes (values
> > > of
> > > 128 and above) are expected in a DCO."  Also, going back to your
> > > statements above about specific behavior resulting from the status
> > > value.  I just want to make sure the specification is clear related
> > > to what should be done; if any value is ok, then the text is, at
> > > minimum not clear...if the behavior depends on the value, then
> > > there's an effect if the
> > value is not that is expected...
> > >
> >
> > That text goes away if you agree with the proposal of the additional
> > bit in the RPL status. The new text would say that "the ARO status
> > MUST be placed unchanged by the root" in the mapped DCO with the bit
> > ARO set. Conversely that the "6LR MUST place the mapped ARO status in
> > the NA(ARO) that is built upon the DCO".
> >
> > RPL already has text like "
> >                   The root of a DODAG is
> >    authoritative for setting that information and the information is
> >    unchanged as propagated down the DODAG.
> > "
> >
> > We can emulate that form for the DCO, say that "The root or common
> > parent that generates a DCO is authoritative for setting the status
> > information and the information is unchanged as propagated down the
> > DODAG. " The transported ARO status is just a case of that. We'd also
> > say that "this spec does not specify a differentiated action based on the
> status."
> >
> >
> > >
> > > I hope we're making progress.  If not, we might want to think about
> > > speaking live. :-)
> >
> > We are. If you agree with the proposed line above I'll make editions
> > and come back to you for more comments and/or approval.
> >
> > This is all very much appreciated, Alvaro.
> >
> > Pascal