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

[Andy Bierman <[e-mail]>]

Hi,

The update is on github.
http://github.com/netconf-wg/rfc6536bis

I would like Martin to look it over before it is posted.


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