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

[Andy Bierman <[e-mail]>]

On Wed, May 24, 2017 at 12:16 AM, Martin Bjorklund <[e-mail]> wrote:

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

OK -- the term NETCONF datastore was used twice, now just datastore.
(pushed to github)

The term datastore appears a lot.  There are 3 variants:

    - datastore
    - configuration datastore
    - target datastore

With revised datastores these are not all the same anymore.
We probably need to go through the entire document and check if the
correct variant is used in each instance.

Are there other terms that are needed for alignment?

Does NACM need to reference the revised-datastores draft to import
terminology?




>
> /martin
>
>

Andy


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