IETF Logo Mail Archive

[Roll] In what way is roll-unaware-leaves updating npdao?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 October 2020 18:18 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1F08F3A0E44 for <roll@ietfa.amsl.com>; Tue, 6 Oct 2020 11:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sDqLigaiPOFy for <roll@ietfa.amsl.com>; Tue, 6 Oct 2020 11:18:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA973A0B5E for <roll@ietf.org>; Tue, 6 Oct 2020 11:18:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BAB6A389AF; Tue, 6 Oct 2020 14:23:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dxelrOgvQmqp; Tue, 6 Oct 2020 14:23:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B33D8389AD; Tue, 6 Oct 2020 14:23:20 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BAA7070D; Tue, 6 Oct 2020 14:18:00 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Alvaro Retana <alvaro.retana@huawei.com>
In-Reply-To: <CAMMESsxgYifi+U=fTdFk5Fz+a1ArbFUzxBbeDeORhk30n2N3Ew@mail.gmail.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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 06 Oct 2020 14:18:00 -0400
Message-ID: <28970.1602008280@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/4JlJOKYAgZCP5Pe0hLQ8BjaIIEs>
Subject: [Roll] In what way is roll-unaware-leaves updating npdao?
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: Tue, 06 Oct 2020 18:18:05 -0000

Alvaro Retana <aretana.ietf@gmail.com> wrote:
    >  === Part 3: remaining comments (based on -18) ===

    > ...  484 5.  Updating draft-ietf-roll-efficient-npdao

    > [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 nodes that support the DCO would support the
    > Non-Storing MOP as well.  Is that what is intended?

    > Note that Updating is different than simply expecting the nodes that
    > implement this specification to comply.

    > [Personal opinion: I don't think a formal Update of
    > draft-ietf-roll-efficient-npdao is needed.  As mentioned below, this
    > document "extends"...]

1) I agree that we are extending, not updating.
   It feels weird to update a document that is in the same cluster :-)

2) The text says:

   [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a
   link-local scope.  This specification extends its use to the Non-
   Storing MOP, whereby the DCO is sent unicast by the Root directly to
   the RAN that injected the DAO message for the considered target.

If an RPL aware node supports RUL, then it has to support DCOs
even when operating in a Non-Storing MOP.

The document does NOT say that a node with RUL support has to support
Non-Storing MOPs.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email