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

Alvaro Retana <aretana.ietf@gmail.com> Tue, 03 May 2022 20:03 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 DFD7CC157B39; Tue, 3 May 2022 13:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 J4yG2-Q94AIo; Tue, 3 May 2022 13:03:53 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 1F83EC14F74A; Tue, 3 May 2022 13:03:53 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id bg25so10466299wmb.4; Tue, 03 May 2022 13:03:53 -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: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; d=1e100.net; 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 gmailapi.google.com with HTTPREST; Tue, 3 May 2022 13:03:50 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <b3eb80f5-cdf5-16b2-43b8-5e422f500970@ariskou.com>
References: <CAMMESszw86VSD7Nw9BbFQ4+3buzy8aRqz_1VaJFbk8o-2UC4=Q@mail.gmail.com> <b3eb80f5-cdf5-16b2-43b8-5e422f500970@ariskou.com>
MIME-Version: 1.0
Date: Tue, 3 May 2022 13:03:50 -0700
Message-ID: <CAMMESsxfRcVSCHN7ok7Mz3eHfCek8AVG-epf6dPdF=-WhCAbbA@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/gg61iVPdPMIwEcEPE8dhE-Xw3LY>
Subject: Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.34
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, 03 May 2022 20:03:57 -0000

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/