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

[Andy Bierman <[e-mail]>]

On Tue, May 23, 2017 at 12:41 PM, Mahesh Jethanandani <
[e-mail]> wrote:

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

OK, but the operations are somewhat NETCONF specific.
We will try to make sure we do not create more inconsistencies than we
remove ;-)


Andy


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