Subject: [Netconf] draft-ietf-netconf-nmda-netconf-03: augment issues

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Feb 2018 19:02:51 -0800

Hi,

The <lock> and <unlock> operations are augmented with a datastore-ref.
The <operational> datastore is read-only (NMDA:5.3) and NETCONF locking
is for write-locking only.

Should the description-stmt mention that this is a "no-op" operation that
has no affect?

The <validate> operation is augmented with a datastore-ref, but validation
is allowed to fail in certain ways for <operational>. Should the
description-stmt
mention this detail and reference NDMA:5.3 ?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Feb 2018 11:03:24 +0100 (CET)

Hi,

> Should the description-stmt mention that this is a "no-op" operation that

The description-stmt currently says:

         If the lock operation is not supported by the server on the
         specified target datastore, then the server MUST return an
         <rpc-error> element with an <error-tag> value of
         'invalid-value'";

Do you think this is ok?

> mention this detail and reference NDMA:5.3 ?

Same thing here, the text says:

         If the validate operation is not supported by the server on
         the specified target datastore, then the server MUST return
         an <rpc-error> element with an <error-tag> value of
         'invalid-value'";

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Feb 2018 09:18:24 -0800

>          <rpc-error> element with an <error-tag> value of

No -- the standard should be clear what a server is expected to support.
Why is it up to the server to decide (and not even disclose to the client)
which datastores support locking?

>          an <rpc-error> element with an <error-tag> value of
same comment here

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Feb 2018 19:13:08 +0100 (CET)

> which datastores support locking?

I think both locking and validation support is a property of the
datastore.  Possibly it is even tied to some additional capability
(compare w/ writable-running).  Maybe a new not-yet-defined dynamic
configuration datastore supports validation but not locking.

The question now is if we need to add more text to the existing
descriptions?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Feb 2018 10:17:35 -0800

> The question now is if we need to add more text to the existing
Then it is the responsibility of the NMDA draft to define these requirements
for <operational>.

I am only concerned about the conventional and operational datastores,
not proprietary or TBD datastores.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Feb 2018 19:33:24 +0100

> which datastores support locking?

I think there are three things we should not confuse:

1) How does a client can learn whether a datastore supports locking?
2) How does a server reacts if a client tries to obtain a lock for a
   datastore that does not support locking.
3) On which datastore is it required that a server supports locking.

The text above handles 2). We could add text say to section 3.2 saying
that <operational> does not support locking (although this may fall
out of the fact that it is read-only as per the NMDA document - so why
would one expect to be able lock it). Concerning 3), section A.4 of
the NMDA document hints at it for future new datastores: "or that a
subset of all protocol operations or capabilities are available (e.g.,
no locking or no XPath-based filtering)."

> >          an <rpc-error> element with an <error-tag> value of

Same as above.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Feb 2018 10:41:12 -0800

> no locking or no XPath-based filtering)."

Issue (3) seems easy - add normative text to the RD draft that says
locking does not apply to <operational>, so <lock> / <unlock> MUST
fail with an rpc-error.

If the :validate capability is advertised, then the server MUST accept
a <validate> request for <operational>.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Feb 2018 17:38:55 +0100 (CET)

Hi,

> locking does not apply to <operational>, so <lock> / <unlock> MUST

We suggest we add text that explains the lock/unlock is only supported
on writable datastores.

> a <validate> request for <operational>.

RFC 6241 describes :validate as:

   Validation consists of checking a complete configuration for
   syntactical and semantic errors before applying the configuration to
   the device.

   ...

         This protocol operation validates the contents of the specified
         configuration.

   Parameters:

      source:

            Name of the configuration datastore to validate, such as
            <candidate>, or the <config> element containing the complete
            configuration to validate.

So it seems valdiate is supposed to be used for configuration data.
We suggest we add text to this draft that for <validate>, an error is
returned if the datastore parameter does not refer to a configuration
datastore (that the server supports).

Do you think that these additions are ok?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Feb 2018 09:11:13 -0800

On Thu, Feb 15, 2018 at 8:38 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > Should the description-stmt mention that this is a "no-op"
> operation
> > > that
> > > > > > has no affect?
> > > > >
yes