Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10

Alvaro Retana <aretana.ietf@gmail.com> Thu, 02 June 2022 16:11 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 78A55C14F692; Thu, 2 Jun 2022 09:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCK4chOpN2Z3; Thu, 2 Jun 2022 09:11:29 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6617C14CF1A; Thu, 2 Jun 2022 09:11:29 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id h62-20020a1c2141000000b0039aa4d054e2so5030464wmh.1; Thu, 02 Jun 2022 09:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=MrRMTKZlnTeE/5DFNrbkofJmlHCQBN4ubuXKh8MHbk0=; b=haZddXfTmSTpegjTsWRESrP8qu5YANXCLMQjeqI6FoDppXhtsFHKmgLyQIzfLf059t 7kSRuS+7c0e81UjA/NbDcqt9qvxRg0zSWhP0JSDyfcJHIwRtfQkAbFuP5MCbf53I5mXB 76lyZI1fImj0TiDJ7vMXXdakdfEzDMJOPGPjm/3VxbT6Gnt2nW0F/NWYeYl/MyFAlhKW 2X55+5ufVkwTqTFf4+gHcfVLPCKi6c6Yf0IFpCmRl4e6TJQcFNnQxrOil6uVwexkM5Nu KrXSqm1/8dteRwqBtcpDiuf4PkjujRYJ6kugLby3YebXay874mn97bWgYATap26ZAteE Kfkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=MrRMTKZlnTeE/5DFNrbkofJmlHCQBN4ubuXKh8MHbk0=; b=1aH9swNuTJwq5U6U8dZkbDDT23OwHrQyargB52CQr0uo9P/28fMiMxY/u6GzJUv33x KyNzbJczmAAx4QhmpqizwCUGYpwAVbFfC0R07UB8uFM58sveaDOcyMiehZEdnqh6sT3z Uo1ZZyjt8fO8ieS2mcrPDnJc3kkv1nvvFdbN+4k43QWr69jcMjAN6ACZxzVeeawGF1BO AyJ8xLWz8OPot8XGhvrg7ka/BW7a1bUKdDDvrjEi/R+uwK9aBXrItzpA7dAKqQ5LkrLE kpX9fWs/DKYKTEPlirRnELgOjXaZeWK7C0cleCcynGpAq7UtKAkoeMo9fLgVazjmtmRh zXMQ==
X-Gm-Message-State: AOAM533dWbrfn2gpY5OJOxEANMeBlstuNivUWoQrXZ+7xGDI8Y8N1luy Pqoyc/Q1D9t3S1ltEs8rMmPkBWz70x7sHyj8l+I=
X-Google-Smtp-Source: ABdhPJyu2hAnuTj40m3f3IIvyo6xcn5LQdGgft0c9aXcjlfaz2qYDC7LaMvOFEf5wnH+pJ4+PY9cZ3RXDndhxvdlzsg=
X-Received: by 2002:a05:600c:1492:b0:397:4afc:cc76 with SMTP id c18-20020a05600c149200b003974afccc76mr4680547wmh.124.1654186287518; Thu, 02 Jun 2022 09:11:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 2 Jun 2022 09:11:26 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESsxfRcVSCHN7ok7Mz3eHfCek8AVG-epf6dPdF=-WhCAbbA@mail.gmail.com>
References: <CAMMESszw86VSD7Nw9BbFQ4+3buzy8aRqz_1VaJFbk8o-2UC4=Q@mail.gmail.com> <b3eb80f5-cdf5-16b2-43b8-5e422f500970@ariskou.com> <CAMMESsxfRcVSCHN7ok7Mz3eHfCek8AVG-epf6dPdF=-WhCAbbA@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 2 Jun 2022 09:11:26 -0700
Message-ID: <CAMMESswGDXfLDdSaHwAndEO-J1izCn5BgpVjjWdVV=cBnO2dug@mail.gmail.com>
To: Remous-Aris Koutsiamanis <aris@ariskou.com>
Cc: Georgios PAPADOPOULOS <georgios.papadopoulos@imt-atlantique.fr>, "draft-ietf-roll-nsa-extension@ietf.org" <draft-ietf-roll-nsa-extension@ietf.org>, roll-chairs <roll-chairs@ietf.org>, dominique barthel <dominique.barthel@orange.com>, roll <roll@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f57c105e07942d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/VxDUkn2h8yq8soX98TIIEiyrdlw>
Subject: Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
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, 02 Jun 2022 16:11:30 -0000

Hi!

Where are we on this?

Thanks!

Alvaro.

On May 3, 2022 at 4:03:50 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

On May 3, 2022 at 10:41:42 AM, Remous-Aris Koutsiamanis wrote:


Aris:

Hi!


> Overall we are in wide agreement with you.

:-)

> Please see inline for responses and we'll work on a revised version
> addressing them:

I just have a couple of comments below.  I look forward to the revised
version.

Thanks!

Alvaro.


...
> > 336 [MRHOF], Section 3.5 "Working without Metric Containers":
> > 337 It is not possible to work without metric containers, since CA AP
> > 338 selection requires information from parents regarding their parent
> > 339 sets, which is transmitted via the NSA object in the DIO Mectric
> > 340 Container.
> >
> > [major] "It is not possible to work without metric containers..."
> >
> > What if the metric container is not present? Is this one of the risks
> > that should also be mentioned in the Security section?
>
> You are right, we assumed that writing what is required (MUST) is
sufficient,
> and specifying fallback options is not necessary if the requirements are
not
> met.
>
> Basically, we were ready to allow implementation-defined behavior when
> operating outside of the required parameters.
>
> Maybe we should specify that a lack of metric container SHOULD lead to
the
> use of MRHOF (i.e with no AP). This way we recommend a full MRHOF
> implementation to be available to fall back on, but if such an
implementation
> is undesirable or another fallback OF is preferable, that instead can be
> used.

Ok -- recommending the fallback will prompt the question: when is it ok to
not fallback to MRHOF?  What should be considered when defining
implementation-specific behaviors?  Also, all the nodes in the LLN should
take the same action, which seems to result in a locally defined OF.

Maybe I'm thinking too much about this.  At least something to think
about...


...
> > [major] How are the different policies provisioned at different nodes?
> > In many instances the root decides about the behavior of the DODAG
> > and propagates that information (all do the same). But in this case
> > all nodes won't have the same configuration. How is that provisioned?
>
> There are a lot of degrees of freedom in approaching this so
> providing some rough suggestions in the Appendix was what
> we though would be the appropriate degree of detail.
> Do you think that more should be explained?

Yes, I understand the complexity.

Let's leave it like it is -- but be aware that the provisioning question
may come up later from others (Ops Directorate, for example).



...
> We think the comment for this got cut-off

Yes, there were some other comments.  I'm not sure why some mailers seem to
cut the text.  The full review is in the archive:
https://mailarchive.ietf.org/arch/msg/roll/QTnFl5T7KlbiST8xSC2zrfJLDKA/