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

Alvaro Retana <> Thu, 16 June 2022 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 411EAC14F743; Thu, 16 Jun 2022 06:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 qWGhw0RKF9F1; Thu, 16 Jun 2022 06:26:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (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 72179C14F722; Thu, 16 Jun 2022 06:26:58 -0700 (PDT)
Received: by with SMTP id m16-20020a7bca50000000b0039c8a224c95so876011wml.2; Thu, 16 Jun 2022 06:26:58 -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=yj8jT+D/x+Rs1cq9LZGLMMQYnAVja6DKL5uIohqzepY=; b=Jv0FPU9FtWzoXiEV/5MlPbKoKbOPqje2aNHFF8g+YYgmMgsPEmC2k67/nT6zW4PKRF uStDR4en4fITjEJSf7wkaQfWkhzqxGopvHQfVEdvA7LimBsJPQnLLsIKv07RR+er1nng /d3uheUHpVRYG9oUIkqnOnoccEmYOFM8wh3GumjNy6yhKlPPIKfOn9Tr6aTZk2X6WSkU DI2GBRhjGHi8R+fV0IZ6uGMPHGpJyWevbGkEpYGkl+7QyJj0wPkvJx9TtOPCzOLE1K7R es9EgDP9YXCKPGwZqp66+UUdPpwMnfpZuXW2bNDQvxzyAFHlszdkakW71nozGMXVBsag Okdg==
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=yj8jT+D/x+Rs1cq9LZGLMMQYnAVja6DKL5uIohqzepY=; b=rUIeKYF3gKq4WEenKf8rgyZlcfFzfTRtzH309mKgvJ/bxKBAUsRfK8md8zUFxxKPIB yXlpRgSGADNVFDaLEn/qH1kYgLhv7bXN5SKlnjYL5pdP0NJei2gykinntm0IA/IjUdKo k+ZBaHfaRg71DmmzPhRasrGmBqpHRtNTxj/zW9fvFiCMUbuPPiVqg895ecDGTqqizmmA LFalnWMJOSynSN9Y1p7ddkwmOjtOqBtt/gnwOINamnQ5vYqMtfXFXkjPZgDZScNxnrp9 +DNm1FajnrXnI52lJj6HbQHzElF0SBOHzEt8sUMiLCg6/ezDlNX6g83GKozTS2GCOwMb z9/A==
X-Gm-Message-State: AJIora9N828zw9B+kPyyFoE7cUf/YHbCQGY+FaVwlLCxNytXnRoXxKP2 wM6p9RcLNbPy3Pro/g2hmY9Mr5S9kZvqfwawJvo=
X-Google-Smtp-Source: AGRyM1uzsWl30VpxXnXHIrwCkifTRTSAX2K6OMfG7djdVzAvsGuKCYJxa8UdVg1sdxx4NFl8aiGwrJHzYYHrrE3asvc=
X-Received: by 2002:a05:600c:384c:b0:39c:58da:44e with SMTP id s12-20020a05600c384c00b0039c58da044emr5053081wmr.124.1655386017006; Thu, 16 Jun 2022 06:26:57 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 16 Jun 2022 08:26:56 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Date: Thu, 16 Jun 2022 08:26:56 -0500
Message-ID: <>
To: Remous-Aris Koutsiamanis <>
Cc: Georgios PAPADOPOULOS <>, "" <>, roll-chairs <>, dominique barthel <>, roll <>
Content-Type: multipart/alternative; boundary="00000000000082892e05e190970b"
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, 16 Jun 2022 13:27:00 -0000

Hi Aris!

No problem — I just needed to know the status. :-)



On June 16, 2022 at 9:11:05 AM, Remous-Aris Koutsiamanis (

Hello Alvaro,

sorry about the delay in answering.

We're doing our best to respond to everything, but this is the end of the
academic year, and a few things have piled up.

We'll try our best to have everything done by around 5 july, maybe earlier,
but it will be hard to set aside some hard constraints.

I hope this is not too problematic. If it is, please do let me know though
(i.e. there some constraint I am not aware of).

Sorry again about the delay.

On 02/06/2022 18:11, Alvaro Retana wrote:


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: