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

[Mahesh Jethanandani <[e-mail]>]

> On May 23, 2017, at 12:15 AM, Martin Bjorklund <[e-mail]> wrote:
> 
> Andy Bierman <[e-mail]> wrote:
>> Hi,
>> 
>> The update is on github.
>> http://github.com/netconf-wg/rfc6536bis
>> 
>> I would like Martin to look it over before it is posted.
> 
> Done, and the new text looks good.  I moved the new subsection to be
> the first in 3.2, and I also fixed some minor terminology issues.
> 
> But, I wonder if we shouldn't make the document even less NETCONF
> specific, and align the terminology to revised-datastores.  For
> example, currently the document talks about access to "NETCONF
> datastores".   With the new less protocol-specific terminology this
> would simply be "datastore”.

I would prefer this.

> 
> Also, we currently have this:
> 
>   A standalone RESTCONF server (i.e., not co-located with a NETCONF
>   server) applies NACM rules to a conceptual datastore, since
>   datastores are not supported in RESTCONF.
> 
> I don't think this is quite correct.  Even in a stand-alone RESTCONF
> server there is an underlying conceptual datastore, for which NACM can
> be used to control access.  
> 
> 
> 
> /martin
> 
> 
>> 
>> 
>> Andy
>> 
>> 
>> On Sun, May 21, 2017 at 10:25 PM, Mahesh Jethanandani <
>> [e-mail]> wrote:
>> 
>>> Andy,
>>> 
>>> On May 16, 2017, at 2:32 PM, Andy Bierman <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 16, 2017 at 2:02 PM, Mahesh Jethanandani <
>>> [e-mail]> wrote:
>>> 
>>>> 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?
>>>> 
>>>> 
>>> No. IMO the text should say NACM applies to NETCONF and RESTCONF
>>> with the existing datastores.
>>> 
>>> NACM MAY be applied to other datastores that have similar operation sets.
>>> Any new datastore specification needs to define how it maps to the NACM
>>> CRUDX
>>> model.  The datastore does not need to use NACM (e.g., datastore defines
>>> something else
>>> or does not use access control).
>>> 
>>> 
>>> Can you update the draft with this text.
>>> 
>>> 
>>> 
>>> 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.
>>>> 
>>>> 
>>> This would be outside the scope of NACM.
>>> This is part of the RPC input validation.
>>> 
>>> 
>>> And clarify that operations outside of CRUDX are outside the scope of
>>> NACM. We can them move the document towards publication.
>>> 
>>> Thanks.
>>> 
>>> 
>>> 
>>> 
>>>> 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?
>>>> 
>>> 
>>> If NACM needs to be changed in the future because a new or existing
>>> protocol needs new features
>>> then the WG will have to deal with it then.
>>> 
>>> 
>>> 
>>>> 
>>>> Thanks.
>>>> 
>>>> 
>>> Andy
>>> 
>>> 
>>>>> 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]
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> Mahesh Jethanandani
>>> [e-mail]
>>> 
>>> 

Mahesh Jethanandani
[e-mail]