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

[Martin Bjorklund <[e-mail]>]

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

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