Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18

Alvaro Retana <aretana.ietf@gmail.com> Thu, 08 October 2020 21:10 UTC

Return-Path: <aretana.ietf@gmail.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 35E143A0D73; Thu, 8 Oct 2020 14:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 hUoWGAeSoUX4; Thu, 8 Oct 2020 14:09:59 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 49D523A0D70; Thu, 8 Oct 2020 14:09:59 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id lw21so10103219ejb.6; Thu, 08 Oct 2020 14:09:59 -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:content-transfer-encoding; bh=9Ly6GCssJrF773XlWNCRSkjhBHwJUrUdzp1q7zvseU8=; b=oefoId0u17j2wwJpto7fmf65XHPRbvkBJcp1DuIP/5ib6cEQiESsmyt56DWlKgS15Y wvoBF07awIP1JgYocxEj48WQjrO9c9o4KCGBLY/glkDLeuXJeNinRUT2BT0C1LVkceBr vbFu2Hh33NiByLmlwUZR44HvNNkxlXSfsh60dr2KiJOGrkafOGV40Ij1mwr93vlxpzo6 BzJd3n39kMc0b4eoRwqE6HW3quY4t6Pf5Yd3fPvfx28yWSQftBWV/u0wGp6WvG8A4X0K heLhmdOmta1fmu13iT8iMm/v74oxRxIvYSdPZTwIVikIkDT9UrJIfqTmEengJ7Tvy4fl Q5gg==
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:content-transfer-encoding; bh=9Ly6GCssJrF773XlWNCRSkjhBHwJUrUdzp1q7zvseU8=; b=p/d/zH3ooABTN6dixMXAzRW1NzBKnXfI0Yc4xEOnItgw8kBqOyXTnc3xbmGCLBSoim cJmeX4bUm5iaJg3bBe0NF2ia4vzxScqtHIKImA5rec8ypJYzLAf7Swv1Vo+qBZhzlV7+ ORClrcoEQUYUat/sdOiPxNBPmwYaPmfP93UIfsdgMEKXz0jtZr/GLF/saRAnnFi2Dg9f v7UTMk1OFrSG5pmVHs+RrMT/BEMAsLIIEBSc7i1vvv7Ib4bekApuxo4cNb/sX0T1sYUM NOVTGK/yl21A0NL3SsKT1ZPA22qp2hvLrY6totyagROwiC3XolTkBYyVVbWlpg7xmji5 5WJQ==
X-Gm-Message-State: AOAM530s4TbkeOCQXKWpVtnyIu7UtLvuAZCfdy7sPbJuXRVSLZ/4q92S EMSst2fKn+aKcHCi49bEfJjzcXp3muTLsgH8sV0=
X-Google-Smtp-Source: ABdhPJzCjvyfmmxv5Pp6UYiPsHqNkjlg6+jjIqfLBRJzf5TpMkW6vx9j8xBCFUUPaZQAV82G6Ch18UuMwNKXsSZprso=
X-Received: by 2002:a17:906:715a:: with SMTP id z26mr10863145ejj.300.1602191397749; Thu, 08 Oct 2020 14:09:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 8 Oct 2020 16:09:56 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CY4PR11MB13529BF16345FBC5279A7AEBD80B0@CY4PR11MB1352.namprd11.prod.outlook.com>
References: <CAMMESszw4SuUQtchiqk-o7Z=62X+U2af4==X5S_=rJ-3y4Dn=w@mail.gmail.com> <MN2PR11MB356593481245BC85A03D4003D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsxgYifi+U=fTdFk5Fz+a1ArbFUzxBbeDeORhk30n2N3Ew@mail.gmail.com> <CY4PR11MB13529BF16345FBC5279A7AEBD80B0@CY4PR11MB1352.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Thu, 8 Oct 2020 16:09:56 -0500
Message-ID: <CAMMESsxNR+4h+3ShfxFY7QcJaehuxd9LXuL7B+rjq5gQSGs2kA@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Rahul Jadhav <rahul.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mHDrNVBvAqtotP9iV-g_LhzgyOo>
Subject: Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18
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, 08 Oct 2020 21:10:01 -0000

On October 8, 2020 at 3:26:36 PM, Pascal Thubert wrote:


Pascal:

Hi!


...
> I did not yet go to the end (went 2/3 down) but I need your advice about
> updating RFC 8505 at the end of the covered piece. So I thought I should
> send you the partial response as of now.

In this message I'm just commenting on what is related to updating
rfc8505.  I'll take a look at the rest later.


Thanks!

Alvaro.


...
> > 494 6. Updating RFC 8505
> >
> > [major] To me, Updating an RFC means that the implementations of that
> > RFC should also implement this one. In this case, there would be an
> > expectation that all 6LRs would support the change. Is that what is
> > intended?
> >
> > Note that Updating is different than simply expecting the nodes that
> > implement this specification to comply...in this case, *if* "the RPL
> > Root advertise[s] the capability...".
> >
> > [Personal opinion: rfc8505 applies to 6LRs in general, not just RPL
> > routers in particular...so I think that Updating it is not the right
> > choice.]
> >
>
> Whao, a difficult one. We update the RFC8505 behavior.
> But not to all type of node that implement RFC 8505. Only those that are
> RPL Routers.
> So what is the most important? That we change the operation of an RFC or
> that the change ios scoped to a subset of nodes?

IMO, the answer is to make the change that is necessary, and no more.


> I'm asking, not proposing and answer. The reason behind is that is another
> RFC updates RFC 8505 with a change that is not compatible, the fact that we
> did not update will make it harder to track.

Yes, this is where an "Extends" or at least "See Also" tag would be
great [1], but we don't have those.

OTOH, the reason we do so many reviews (WG, directorates, IETF LCs,
etc.) is to get also cross-area review.  This should catch
incompatible changes.  Yes, I realize this is the ideal situation, and
that a change like this may still be missed... :-(

The risk is then that the process doesn't work; i.e. that people don't
do good reviews. :-(


Having said all that, if you (the WG) want to change the behavior for
all the nodes, then we'll need positive confirmation from 6lo that
this is ok.  I seem to remember that there was already communication
with 6lo about the proposed changes, and there was no opposition.  I
can go find that thread again...

Given the text in this document (like the sentence below for example
-- and what you said above), it doesn't seem to me that making a
change for all the nodes (vs. just RPL routers) was the WGs intent.
So we'll have to confirm that as well.

Also, we'll probably need to generalize the specification to not be
specific to RPL.  But with any RPL-specific normative behavior
highlighted.


What do you want to do?


[1] https://tools.ietf.org/html/draft-kuehlewind-update-tag


> > 496 This document updates [RFC8505] to change the behavior of a RPL
> > 497 Router acting as 6LR in the 6LoWPAN ND Address Registration of a
> > RUL
> > 498 acting as 6LN. If the RPL Root advertise the capability to proxy the
> > 499 EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the
> > 500 keep-alive EDAR message. Instead, if it is separated from the 6LBR,
> > 501 the Root regenerates the EDAR message to the 6LBR periodically,
> > upon
> > 502 a DAO message that signals the liveliness of the Address.





...
> 12.2. Resizing the ARO Status values
...
> > [major] Changing the range of values is not as easy as updating the
> > registry...the behavior of the EARO and ARO have to be updated. This
> > means that this document should Update both rfc6775 and rfc8505 where
> > it relates to the redefined Status field.
>
> Isn't this transitive? I mean the field defined in RFC 6775 is updated by
> RFC 8505.

No.  As far as I understand it, rfc8505 didn't change the behavior of
the ARO, it extended it.  In fact, the changes are backward
compatible, which tell me that the ARO (independent of an EARO) is
still valid and expected to work.  I would be happy to be corrected.

It may be that no one cares about changes to the ARO anymore...but
that is a different conversation.  And updating only the EARO seems to
break the backward compatibility.


> Maybe the 6lo group should clarify that the ARO is deprecated somehow?

That would be nice...but that is not what rfc8505 says.