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

[Remous-Aris Koutsiamanis <[e-mail]>]

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