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

Alvaro Retana <> Tue, 03 May 2022 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFD7CC157B39; Tue, 3 May 2022 13:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 J4yG2-Q94AIo; Tue, 3 May 2022 13:03:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (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 1F83EC14F74A; Tue, 3 May 2022 13:03:53 -0700 (PDT)
Received: by with SMTP id bg25so10466299wmb.4; Tue, 03 May 2022 13:03:53 -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:content-transfer-encoding; bh=g1lLIkmw6GBQxJQFqliXyv4onyHUvD6XDD0dO7ILHig=; b=nG0vcSnv4qRgBD7Wzo4cjTQgjoKGYvTl0SFskdKIhO1BnfTj449HQpAswnCp/AWJyC vbQN5J20nMRgJFT8oWnFprsOcr1il6uaa8Z23IN5ZNooshK6fkaOxPbJlURpv9MW2TNA IP0IxUhdAwfErvtEZaoeSFCvu4AnUtcQTch3EkOE2qrQyq9sSk5oMnH+sRFSf1uIH3Jx zdkr+CHBNywLoO+HcMVH9tI/JofhMuzzRKmUy+480oMuMjrpBPNmPy5eBLvNfjHEFaM2 i8mY1Ktb4vGEMIEHV9cGLEGzsXoML/fjeJUF6n4AerNDNRir4kUWyH+74NUjO2TXRSMx n0AQ==
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:content-transfer-encoding; bh=g1lLIkmw6GBQxJQFqliXyv4onyHUvD6XDD0dO7ILHig=; b=wg7Igh/74ooSNzE31Nsvk6UdgxgAvDNqk6rJjxh8mpuK9t+Xq2eGC+KkIn257oHl5t FBELESBNQwETSRBQMKKT23OMYKmVELH1N1IxQfmAMIfoYrcMD13QrDWfz5RNtNX4HZ5f HqVXVVqHnP6npx6XtFcmn0UJOzmpdFfA+Nb7UvNYbx3WQAWNXoonZLN9+cZ/O+Lwrh1v ayqy/17fuQtN/nNf5qiaf6N8NZEeGj0oBa8luRa8ojv4/Vbx1ZTRf6rSJZ0vqb7UZ0ZU rar4IHim6glCofBvNiookhy0CUNferElxJL78yWOA7fOk8EE/jyiD3TeTSO/QqHe/GOT XD9A==
X-Gm-Message-State: AOAM533YOVnOvsDq9KCOmmtVlm0cgKREAlHXx4/cgSESMmv23uWxHJbD xGRIH192pp6mT7nwcYyOT1IE6NbGa18+6PFnItI=
X-Google-Smtp-Source: ABdhPJwBcaGj+r9pQF7e9NKQc7FZLsszyQsDctPz5dEXU/zNci067wu31BiywXkC3RhXa8qk2DkRnwsk2Lgj1FvAgAo=
X-Received: by 2002:a7b:c4c8:0:b0:394:26c5:b79e with SMTP id g8-20020a7bc4c8000000b0039426c5b79emr4748946wmk.15.1651608231158; Tue, 03 May 2022 13:03:51 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 3 May 2022 13:03:50 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Tue, 3 May 2022 13:03:50 -0700
Message-ID: <>
To: Remous-Aris Koutsiamanis <>
Cc: Georgios PAPADOPOULOS <>, "" <>, roll-chairs <>, dominique barthel <>, roll <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10
X-Mailman-Version: 2.1.34
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: Tue, 03 May 2022 20:03:57 -0000

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 version.



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