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

[Alvaro Retana <[e-mail]>]

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/