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

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> 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 ;-)

Yes.  But I think what we should do is not any technical changes, just
align terminology.


/martin



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