Subject: [Netconf] draft-ietf-netconf-restconf-16

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Sep 2016 15:23:27 +0200

Dear RESTCONF authors,

While waiting for a resolution on "restconf confusing text" (see the 
email with that subject), Mehmet and I are checking if v16 correctly 
addresses the different feedback received so far.

While checking the diff, I'm wondering about two points:

- Any reason why this text is not in section 1.4?
Maybe I should have commented on this earlier, but the last paragraph 
below, which is new text, triggered that thought.

        The following figure shows the system components if a RESTCONF server
        is co-located with a NETCONF server:

              +-----------+           +-----------------+
              |  Web app  | <-------> |                 |
              +-----------+  RESTCONF | network device  |
                                      |                 |
              +-----------+           |   +-----------+ |
              | NETCONF   | <-------> |   | datastore | |
              | Client    |  NETCONF  |   |           | |
              +-----------+           |   +-----------+ |
                                      +-----------------+

        The following figure shows the system components if a RESTCONF server
        is implemented in a device that does not have a NETCONF server:

              +-----------+           +-----------------+
              |  Web app  | <-------> |                 |
              +-----------+  RESTCONF | network device  |
                                      |                 |
                                      +-----------------+

        Note that there are no interactions at all between the NETCONF
        protocol and RESTCONF protocol.  It is possible that locks are in use
        on a RESTCONF server, even though RESTCONF cannot manipulate locks.
        In such a case, the RESTCONF protocol will not be granted write
        access to data resources within a datastore.

-

OLD:
    In addition, the
    RESTCONF server will return an error if the datastore is locked by an
    external source (e.g., NETCONF server).

NEW:
    In addition, the
    RESTCONF server MUST return an error if the datastore is locked by an
    external source (e.g., NETCONF server)

Regards, Benoit

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Sep 2016 10:39:02 -0400

>         is co-located with a NETCONF server:

I may be missing something, but comparing the two diagrams says to me
that if the device does not implement NETCONF, then it need not have a
datastore.  But it seems to me that RESTCONF is defined in terms of
operations on a datastore (which is defined by a bunch of Yang
modules).  (Though the datastore can be simpler, as it need not
implement any locking/transaction operations).)

>     external source (e.g., NETCONF server)

That change makes sense to me.  IIRC, somewhere in the RESTCONF
specification is what specific error the server must return.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Sep 2016 10:06:16 -0700

On Thu, Sep 8, 2016 at 6:23 AM, Benoit Claise <[email-masked]> wrote:

> Dear RESTCONF authors,
>
> While waiting for a resolution on "restconf confusing text" (see the email
> with that subject), Mehmet and I are checking if v16 correctly addresses
> the different feedback received so far.
>

You want this text moved from sec. 1.2 to sec. 1.4.  Fine.

>    external source (e.g., NETCONF server)

You want 'will' changed to 'MUST' in sec. 3.4.1.  Fine.

> Regards, Benoit

Andy