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

Alvaro Retana <> Thu, 02 June 2022 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78A55C14F692; Thu, 2 Jun 2022 09:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZCK4chOpN2Z3; Thu, 2 Jun 2022 09:11:29 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id B6617C14CF1A; Thu, 2 Jun 2022 09:11:29 -0700 (PDT)
Received: by 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;; 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;; 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 with HTTPREST; Thu, 2 Jun 2022 09:11:26 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Thu, 2 Jun 2022 09:11:26 -0700
Message-ID: <>
To: Remous-Aris Koutsiamanis <>
Cc: Georgios PAPADOPOULOS <>, "" <>, roll-chairs <>, dominique barthel <>, roll <>
Content-Type: multipart/alternative; boundary="0000000000000f57c105e07942d9"
Archived-At: <>
Subject: Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10
X-Mailman-Version: 2.1.39
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: Thu, 02 Jun 2022 16:11:30 -0000


Where are we on this?



On May 3, 2022 at 4:03:50 PM, Alvaro Retana ( wrote:

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



> 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



> > 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
> and specifying fallback options is not necessary if the requirements are
> 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
> 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
> 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

> > [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: