From nobody Wed Oct 28 08:17:17 2020 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 5740B3A0A83; Wed, 28 Oct 2020 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IIGufcaZA4js; Wed, 28 Oct 2020 08:17:10 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC0A3A0A8D; Wed, 28 Oct 2020 08:17:10 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id dn5so5532773edb.10; Wed, 28 Oct 2020 08:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=74CGm1aCbZOsQyyy9vZgPxCXIf5Ml6K2qSWi91kgeJo=; b=DGeitdgPAcAwp//5UzPyQNmwKYoQ2Q3DPNnC57p5BCd5H+4ltmqzGm1kvMldIiRDEP dqA2V163HnjViVc3LAN7gcitlBOxTB2DoH8N9t0Np8RAL8pAy0ykQSFz2GOCf3WhGO1X wSM3Zj1f5sj9yU6J7Fixa5j/8Y34f+Dfh0LUl9waC0UYRSVS3vR8B7DQFPmZa0ldA7Pj 2KbnXpb1z9kyvkrk6T0eLAlZWqrOw3NmGMKjlXHLoh6cpwzV6ok8QXUUsQ4VxDwR1x3U +Yr2MegqF2GtSYeGS1hcozVJiB9BcyRuy4Hxe2VB18vI8arul4+nsB6LoH9FHXFSFgmj e1lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=74CGm1aCbZOsQyyy9vZgPxCXIf5Ml6K2qSWi91kgeJo=; b=LTbx69Cs/3aIvEuF1ItjBhTYwdYLPJA0ZYkOpypnu/maal2Cyx8Ejv88KIWNY77eu5 2VtchDzM1It4zAsP+5EVa10Zs1xLtCyw3FY7fQ9tPo1Z5blvhnRgPL0Fb21sZe+SA9xU GavESxI/UqgsjQ7djh3H15Fn3juS0eMHY8gJWr5FWavVLWDyzC0Rn5H+bxL5kBBCviYH jpXiyHpusWo2uYdhE3r/jy00MqR7YiC3XepvHNUJEEVItJSOAV4BZR66vAbYwNnRAk/F EXD1Whi6OxOeXnnRfWZFAmULuCyR7biuA0r/Lrm+fl263HG8UzwZEZ9bqrcaqQClcv2L P0lg== X-Gm-Message-State: AOAM533mbVXq19YnMC3lnSh0mPSwOrO7Avm1LK7yMV/m5x5dIfB0SAgm B3HdqtzT6yYwgj3tD0v7q2HAaY8TNAc4C3LrOWE= X-Google-Smtp-Source: ABdhPJxgQaYLN0s5fX5L9Lc6eMhZ2iLayONTHuOk3tSUVyH/M19gWXCuJ5mlzEfHefmHpSkCLkeElzhJO5Zobh1bnDE= X-Received: by 2002:a05:6402:1cbb:: with SMTP id cz27mr7890773edb.38.1603898228657; Wed, 28 Oct 2020 08:17:08 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Oct 2020 08:17:07 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 28 Oct 2020 08:17:07 -0700 Message-ID: To: "Pascal Thubert (pthubert)" , Rahul Jadhav Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000002cd3bd05b2bca879" Archived-At: Subject: Re: [Roll] Deprecating DCO status 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: Wed, 28 Oct 2020 15:17:12 -0000 --0000000000002cd3bd05b2bca879 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! The last part (=E2=80=9CThis specification adds=E2=80=A6=E2=80=9D) is not c= orrect, as unaware-leaves is the one defining the value. Maybe =E2=80=9CThis specific= ation uses=E2=80=A6=E2=80=9D would be more appropriate. Rahul: Please don=E2=80=99t submit anything yet. Because IANA already cre= ated the registry (from the efficient-npdao draft), I want to check with them what is the right thing to do: if we just delete the registry, or if we need to leave it and deprecate it somehow. Thanks! Alvaro. On October 28, 2020 at 11:06:39 AM, Pascal Thubert (pthubert) ( pthubert@cisco.com) wrote: Hello Rahul I believe that you need to indicate that the status is a RPL Status and refer to section 6.5.1. of RPL " Format of the DAO-ACK Base Object". I'm sure Alvaro will propose an improvement but my knee jerk: Before: Status: Indicates the completion status. Section 12.5 of [I-D.ietf-roll-unaware-leaves] defines the status values. A value of 0 is defined as unqualified acceptance. A value of 1 is defined as "No routing-entry for the indicated Target found". After: Status: RPL Status indicating the completion. The RPL Status is defined in section 6.5.1. of [RFC 6550] and updated in section 6.3 of [I-D.ietf-roll-unaware-leaves]. This specification adds the RPL rejection value ('E' flag set and 'A' flag not set) of 1, defined as "No routing-entry for the indicated Target found". Works? Take care; Pascal > -----Original Message----- > From: Rahul Jadhav > Sent: mercredi 28 octobre 2020 13:43 > To: Pascal Thubert (pthubert) > Cc: Alvaro Retana ; roll-chairs@ietf.org; Routing > Over Low power and Lossy networks > Subject: Re: Deprecating DCO status > > Hi Pascal, Alvaro, > > I am mostly clear on the changes required. Please find attached an HTML-diff > for the suggested changes. > The only concern for me was if we remove the registry where would the Status > 1 indicating "No routing-entry for the indicated Target found". > But I see that unaware-leaves has made an update to its IANA section to > include this status. So it works. > Thus, I am referencing unaware-leaves for Status values. > > Regards, > Rahul > > On Wed, 28 Oct 2020 at 14:44, Pascal Thubert (pthubert) > wrote: > > > > Hello Rahul: > > > > > > > > Attracting your attention on the particular point below in Alvaro=E2=80= =99s AD review > of unaware leaves: > > > > > > > > > > So we should update the NPDAO draft and remove that entry shouldn't > we? > > > > > > Note that NPDAO is already in missref because of this draft > > > > > > https://www.rfc-editor.org/cluster_info.php?cid=3DC310 > > > > > > > > > > Yes. > > > > > > > > > > Also, the specification of the DAO-ACK needs to be changed to at > > > least make it > > > > > clear that the "DCO-ACK Status" field refers to the "RPL Status". > > > > > > > > > > About deprecating the registry... We should ask IANA what to do: > > > they already > > > > > created the registry, but the efficient-npdao hasn't been published > > > as an > > > > > RFC. I don't know if we just delete =C2=A76.2 or if we have to formal= ly > > > deprecate the > > > > > registry (possible in this document). > > > > > > > > > > Please ack to this to make sure we're in sync before asking IANA. > > > > > > > > The change Alvaro and I want to make in the efficient npdao draft is > > that the DCO status is now of the same type as the RPL status in DAO > > ACK, and should be specified as such in > > https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-18#section > > -4.3.4 > > > > Which means that we do not need the registry that we ask for in > > https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-18#page-17 > > > > > > > > Do you agree? > > > > > > > > Keep safe! > > > > > > > > Pascal > > > > --0000000000002cd3bd05b2bca879 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Hi!

The last part = (=E2=80=9CThis specification adds=E2=80=A6=E2=80=9D) is not correct, as una= ware-leaves is the one defining the value.=C2=A0 Maybe =E2=80=9CThis specif= ication uses=E2=80=A6=E2=80=9D would be more appropriate.


Rahul: =C2=A0Please don=E2=80=99t submit anything ye= t.=C2=A0 Because IANA already created the registry (from the efficient-npda= o draft), I want to check with them what is the right thing to do: if we ju= st delete the registry, or if we need to leave it and deprecate it somehow.= =C2=A0

Thanks!

Alvaro.

On October 28, 2020 at 11:06:39 AM, Pascal Thubert= (pthubert) (pthubert@cisco.com) = wrote:

Hello Rahul

I believe that you need to indicate that the status is a RPL Status and= refer to section 6.5.1. of RPL " Format of the DAO-ACK Base Object&q= uot;. I'm sure Alvaro will propose an improvement but my knee jerk:

Before:

Status: Indicates the completion status. Section 12.5 of [I-D.ietf-rol= l-unaware-leaves] defines the status values. A value of 0 is defined as un= qualified acceptance. A value of 1 is defined as "No routing-entry f= or the indicated Target found".

After: =20

Status: RPL Status indicating the completion. The RPL Status is defined= in section 6.5.1. of [RFC 6550] and updated in =20
section 6.3 of [I-D.ietf-roll-unaware-leaves]. This specification adds= the RPL rejection value ('E' flag set and 'A' flag not set= ) of 1, defined as "No routing-entry for the indicated Target found&q= uot;.

Works?

Take care;

Pascal


> -----Original Message-----
> From: Rahul Jadhav <rah= ul.ietf@gmail.com>
> Sent: mercredi 28 octobre 2020 13:43
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Alvaro Retana <ar= etana.ietf@gmail.com>; roll-= chairs@ietf.org; Routing
> Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: Deprecating DCO status
> =20
> Hi Pascal, Alvaro,
> =20
> I am mostly clear on the changes required. Please find attached an= HTML-diff
> for the suggested changes.
> The only concern for me was if we remove the registry where would = the Status
> 1 indicating "No routing-entry for the indicated Target found= ".
> But I see that unaware-leaves has made an update to its IANA secti= on to
> include this status. So it works.
> Thus, I am referencing unaware-leaves for Status values.
> =20
> Regards,
> Rahul
> =20
> On Wed, 28 Oct 2020 at 14:44, Pascal Thubert (pthubert)
> <pthubert@cisco.com&g= t; wrote:
> >
> > Hello Rahul:
> >
> >
> >
> > Attracting your attention on the particular point below in Al= varo=E2=80=99s AD review
> of unaware leaves:
> >
> >
> >
> > > > So we should update the NPDAO draft and remove that= entry shouldn't
> we?
> >
> > > > Note that NPDAO is already in missref because of th= is draft
> >
> > > > https://www.rfc-editor.org/cluster_info.php?cid=3DC310
> >
> > >
> >
> > > Yes.
> >
> > >
> >
> > > Also, the specification of the DAO-ACK needs to be chang= ed to at
> > > least make it
> >
> > > clear that the "DCO-ACK Status" field refers t= o the "RPL Status".
> >
> > >
> >
> > > About deprecating the registry... We should ask IANA wh= at to do:
> > > they already
> >
> > > created the registry, but the efficient-npdao hasn't= been published
> > > as an
> >
> > > RFC. I don't know if we just delete =C2=A76.2 or if= we have to formally
> > > deprecate the
> >
> > > registry (possible in this document).
> >
> > >
> >
> > > Please ack to this to make sure we're in sync before= asking IANA.
> >
> >
> >
> > The change Alvaro and I want to make in the efficient npdao d= raft is
> > that the DCO status is now of the same type as the RPL status= in DAO
> > ACK, and should be specified as such in
> > https://tools.ietf.org/html/draft-ietf-roll-efficient= -npdao-18#section
> > -4.3.4
> >
> > Which means that we do not need the registry that we ask for = in
> > https://tools.ietf.org/html/draft-ietf-roll-efficient= -npdao-18#page-17
> >
> >
> >
> > Do you agree?
> >
> >
> >
> > Keep safe!
> >
> >
> >
> > Pascal
> >
> >
<= /div> --0000000000002cd3bd05b2bca879--