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

[Alvaro Retana <[e-mail]>]

Hi Aris!

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

Thanks!

Alvaro.

On June 16, 2022 at 9:11:05 AM, Remous-Aris Koutsiamanis ([e-mail])
wrote:

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.

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

Hi!

Where are we on this?

Thanks!

Alvaro.

On May 3, 2022 at 4:03:50 PM, Alvaro Retana ([e-mail]) wrote:

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/