Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

[Mahesh Jethanandani <[e-mail]>]

Having reviewed all the e-mails, I believe that there are few issues that need to be resolved before we send the draft for publication. We need to agree on the language, even if we do have the exact text in the draft.

To begin with, do the authors have a response to the suggestions from Juergen prompted by the question from Alex? Are we leaving the NACM definition of any future datastores to the datastore draft, or are we saying NACM applies to all datastores?

To the point that Andy raised earlier, we need to have texts around datastores that provide more than CRUDX capabilities, including any protocol operations, e.g. priority, as something that is out of scope of this document.

NETCONF WG has moved to redefine its charter beyond NETCONF and RESTCONF. Therefore there is a real possibility of another protocol being discussed in the WG. Is there something in the NACM draft that restricts it to NETCONF/RESTCONF that other protocols cannot adopt? If so, can they be called out?

Thanks.

> On May 9, 2017, at 11:46 PM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Tue, May 09, 2017 at 02:50:30PM +0200, Martin Bjorklund wrote:
>> Andy Bierman <[e-mail]> wrote:
>>> On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <[e-mail]
>>>> wrote:
>>> 
>>>> As mentioned in my message, I don’t think specific access control will be
>>>> needed (I am not aware of specific use cases), but specifically with the
>>>> revised datastore architecture about to the be introduced, its impact or
>>>> nonimpact and interrelation with NACM should be discussed.  This can be as
>>>> simple as a small paragraph or subsection “Revised Datastore
>>>> Considerations”.
>>>> 
>>>> 
>>>> 
>>> 
>>> there is no text about candidate vs. running vs. startup.
>>> The NACM rules apply to all of them the same.
>>> I could add text that says there is no consideration for specific
>>> datastores.
>> 
>> Actually, the document already says:
>> 
>> 3.2.  Datastore Access
>> 
>>   The same access control rules apply to all datastores, for example,
>>   the candidate configuration datastore or the running configuration
>>   datastore.
>> 
>>   Only the standard NETCONF datastores (candidate, running, and
>>   startup) are controlled by NACM.
>> 
>> 
>> Somehow this needs to be updated when the revised datastore work is
>> done.  E.g., I expect read access to intended to follow the same NACM
>> rules.
>> 
> 
> Yes. NACM likely also applies to the <operational/> datastore (but
> this follows already from the text that talks about 'state data').
> 
> My question, however, was about other future yet to be defined
> 'dynamic' datastores - does NACM make a statement of the form 'once an
> implementation announces NACM, NACM applies to all datastores - no
> exceptions' or do we leave it to the definition of future datastores
> to declare whether NACM applies to it. There may be three possible
> solutions:
> 
> a) Once an implementation supports NACM, NACM applies to all
>   datastores (including any datastores defined in the future).
> 
> b) Once an implementation supports NACM, NACM applies to all
>   conventional datastores and the operational state datastore.  Other
>   datastores must define whether NACM applies to them.
> 
>   (This means, whenever a new datastore is introduced, the question
>   whether NACM applies has to answered for the new datastore.)
> 
> c) Once an implementation supports NACM, NACM applies to all current
>   and future datastore unless explicitely stated or signaled that
>   NACM does not apply to a certain future datastore.
> 
>   (This is essentially b) but with a default that NACM applies unless
>   things are explicitly regulated to be different.)
> 
> I just thought it is worth to take a moment to think about this
> question.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[e-mail]