Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> I have some questions about these drafts.
> 
> 1) what if datastore set to "conventional"?
>     There are many places where a datastore-ref type is used.
>     However, "conventional" is valid for base "datastore", even though
>     it is ambiguous as a datastore selector.

For edit-data, the text says:

        leaf datastore {
          type ds:datastore-ref;
          description
            "Datastore which is the target of the edit-data operation.

             If the target datastore is not writable, then the server
             MUST return an <rpc-error> element with an <error-tag>
             value of 'invalid-value'";

So from this it follows that if the client sends "conventional", the
server will reply with an 'invalid-value' error.

Maybe we can even clarify:

             If the target datastore is not writable, or is not
             supported on the server, then the server
             MUST return an <rpc-error> element with an <error-tag>

There is similar text for lock/unlock/validate.

But for get-data, the text just says:

        leaf datastore {
          type ds:datastore-ref;
          ...
          description
            "Datastore from which to retrieve data.";

I think we should add text:

  If the datastore is not supported on the server, , then the server
  MUST return an <rpc-error> element with an <error-tag> value of
  'invalid-value'.

> 2) origin filter is limited to 1 source
>    This filtering seems rather limited.  A client must retrieve
> <with-origin> and check
>     all the values in use, then make repeated requests for each source as a
> different
>     <origin-filter> leaf

Since "AND" of origins doesn't really make any sense, I think we can
make this a leaf-list and explain that these values are OR:ed.  Do you
think this would be a good idea?

> 3) with-defaults broken
>     The operational datastore does not support with-defaults.
>      Instead, the client must use origin-filter=or:default or with-origin
>      and check all the origin attributes.  Since a client needs to use
>      with-defaults for other datastores, this special handling of
> <operational>
>      seems unhelpful.

The "with-defaults" feature is mostly useful in configuration
datastores, where the client needs to understand how the server treats
defaults.  When the server starts to operationally use config data, it
will also take default values into account and use these values, just
as if they had been explicitly configured.  default values are "in
use" and thus present in the operational state datastore (which by
definition contains all values that are in use).  Since these values
are present in the datastore, they are always returned.  If for some
reason a default value is NOT used, the leaf will not be present in
<operational>, and it will not be reported.

/martin

> 
> 
> Andy
> 
> 
> On Tue, Jan 30, 2018 at 10:27 AM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
> 
> > Authors and WG,
> >
> > We have not received any explicit support for this LC on this email
> > thread. If you believe these drafts are important and should proceed,
> > please state your support by responding to this email thread.
> >
> > Thanks.
> >
> > > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani <
> > mjethanandani@gmail.com> wrote:
> > >
> > > The authors of draft-ietf-netconf-nmda-netconf and
> > draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and
> > believe that the documents are ready for LC.
> > >
> > > This starts a 2 week LC on the two drafts that will end on January 31.
> > Please send your comments on this thread. Comments like “I have reviewed
> > the documents and believe they are ready for publication”, or “I have
> > concerns about the document because …” are welcome and useful for the
> > authors.
> > >
> > > Authors please indicate whether you are aware of any IPR for either of
> > the drafts.
> > >
> > > Thanks.
> > >
> > > Mahesh & Kent
> > >
> >
> > Mahesh & Kent
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >