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: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.
> >
> >
> OK
> 
> 
> 
> > 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 not to make more changes.
> I think it is OK for NETCONF, RESTCONF, and any protocols based on them.
> 
> 
> 
> > 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.
> >
> >
> 
> I do not agree there is any RESTCONF requirement to implement datastores,
> just the ability to apply NACM to the conceptual configuration datastore.
> 
> The text says there is an underlying conceptual datastore, so what is the
> issue?

All datastores are conceptual.  The problem is that the text is
contradictory - it says that RC applies NACM to a datastore, since RC
doesn't support datastores.  This doesn't make sense.

Maybe we can simply remove this sentence.


/martin




> 
> 
> 
> >
> >
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > >
> > > 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]
> > > >
> > > >
> >