Subject: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Jul 2016 18:52:13 +0200

Dear all,

Now that RESTCONF progressed, here is my 
draft-ietf-netconf-yang-patch-10 AD review.

- I see one issue at https://github.com/netconf-wg/yang-patch/issues. Is 
this integrated?

- This is a comment for the RESCONF draft: 
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6

OLD:

    Please see
    [I-D.ietf-netconf-yang-patch 
<https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#ref-I-D.ietf-netconf-yang-patch>] for an alternate media-type supporting
    the ability to delete child resources.  The YANG Patch Media Type
    allows multiple sub-operations (e.g., merge, delete) within a single
    PATCH operation.

NEW (change . by :):

    Please see
    [I-D.ietf-netconf-yang-patch 
<https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#ref-I-D.ietf-netconf-yang-patch>] for an alternate media-type supporting
    the ability to delete child resources: The YANG Patch Media Type
    allows multiple sub-operations (e.g., merge, delete) within a single
    PATCH operation.

- Editorial
OLD:

    An "ordered edit
    list" approach is needed to provide client developers with more
    precise client control of the edit procedure than existing
    mechanisms.

NEW:
    An "ordered edit
    list" approach is needed to provide client developers with more
    precise client control of the edit procedure than existing
    mechanisms [RESTCONF].

Btw, is this more precise? Or it offers more capabilities?
It's only when reading through the doc that we discover the advantages 
versus the plain patch
- ordered collection of edits, while 
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 
is for a single edit
- an edit operation (create, delete, insert, merge, move, replace, 
remove), while 
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6
   is for create or update
- patch-id
- etc...
I've been missing a section about the advantages compared to the plain 
PATCH somewhere at the beginning of the doc.

Btw, I guess that nothing prevents a RESTCONF server to support 
simultaneously the plain PATCH ( 
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6) 
and the PATCH in this document? However, doing so, would provide a 
useless audit log, since the plain PATCH doesn't have a patch-id

       leaf patch-id {
            type string;
            description
              "An arbitrary string provided by the client to identify
               the entire patch.  This value SHOULD be present in any
               audit logging records generated by the server for the
               patch. Error messages returned by the server pertaining
               to this patch will be identified by this patch-id value.";
          }

Worth writing some text about it?

- Terminology
Same remark as for the RESTCONF draft v13: RESTCONF server, NETCONF 
server, server.
"Server" according to the terminology section is the RFC6241 definition, 
so server = NETCONF server.

    A "YANG Patch" is an ordered list of edits that are applied to the
        target datastore by the server

So this sentence contradicts:

    It may be possible to use YANG Patch with other protocols besides
    RESTCONF.  This is outside the scope of this document.

Please apply the same changes as for RESTCONF

    o  RESTCONF client: a client which implements the RESTCONF protocol.
       Also called "client".

    o  RESTCONF server: a server which implements the RESTCONF protocol.
       Also called "server".

- Terminology:

        1.1.2
        <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-1.1.2>.
        HTTP

    The following terms are defined in [RFC7230 <https://tools.ietf.org/html/rfc7230>]:

    o  header field

    o  message body

    o  method

    o  query

    o  request URI

Throughout the doc.: message body => message-body
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14  mentions:
	- header and not header field
	- message-body and not message body
	- method referenced from RFC7231, not RFC7230

- Inconsistencies between the RESTCONF and PATCH terminology:
draft-ietf-netconf-yang-patch refers to the RESTCONF "YANG data 
template" definition.

However, in the RESTCONF doc:

       YANG data template: a schema for modeling a conceptual data
       structure in an encoding-independent manner.  It is defined with
       the "yang-data" extension, found inSection 8 
<https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-8>._It has a representation with the media-type "application/yang-data+xml" 
or "application/yang-data+json"._

draft-ietf-netconf-yang-patch mentions:

       o  YANG Patch: a conceptual edit request using the "yang-patch"_YANG data template_, defined inSection 3 
<https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-3>.  In HTTP, refers to a PATCH
       method where a representation_uses either the media type "application/yang-patch+xml" or 
"application/yang-patch+json"._

Same remark for:

        o  YANG Patch Status: a conceptual edit status response using the
           YANG "yang-patch-status" YANG data template, defined inSection 3
    <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-3>.
           In HTTP, refers to a response message for a PATCH method, where it
           has a representation with either the media type "application/
           yang-data+xml" or "application/yang-data+json".

- 1.1.6.  Tree Diagrams
Should be renamed to "tree diagram notations"

- Is the YANG Patch valid for both YANG 1.0 and YANG 1.1?
RESTCONF is:

      This document defines an HTTP [RFC7230 <https://tools.ietf.org/html/rfc7230>] based protocol called
        RESTCONF, for configuring data defined in YANG version 1 [RFC6020 <https://tools.ietf.org/html/rfc6020>] or
        YANG version 1.1 [I-D.ietf-netmod-rfc6020bis
    <https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#ref-I-D.ietf-netmod-rfc6020bis>], using the datastore
        concepts defined in NETCONF [RFC6241 <https://tools.ietf.org/html/rfc6241>].

Apparently, the YANG patch is only valid for YANG 1.1:

       There is a need for standard mechanisms to patch datastores defined
        in [RFC6241 <https://tools.ietf.org/html/rfc6241>], which contain conceptual data that conforms to schema
        specified with YANG [I-D.ietf-netmod-rfc6020bis
    <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#ref-I-D.ietf-netmod-rfc6020bis>].

- Section 2.1

    The YANG Patch operation uses the RESTCONF target resource URI to
    identify the resource that will be patched.  This can be the
    datastore resource itself, i.e., "{+restconf}/data", or it can be a
    configuration data resource within the datastore resource, e.g.,
    {+restconf/data/ietf-interfaces:interfaces".

What would be an example of the datastore resource itself?

- I received this feedback, directly sent to me.

          2.2
          <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-2.2>. 
          yang-patch Input

        A data element representing the YANG Patch is sent by the client
    to   specify the edit operation request.  When used with the HTTP
    PATCH   method, this data is identified by the YANG Patch media type.

    What does data element mean?  Where is its definition?

    2.2. yang-patch Input
    Should be yang-patch request or something that someone not familiar
    with the netconf RPC concept can related to in the HTTP world which
    this I-D is for.

    2.3. yang-patch-status Output
    Should be yang-patch response.  Same reason as above.

-
section 2.5

    | remove        | remove a data resource if it already exists or no |
    |               | error                                             |
    +---------------+---------------------------------------------------+

NEW:

    | remove        | remove a data resource if it already exists or no |
    |               | error                                             |
    +---------------+---------------------------------------------------+

First, after reading further below, “or no error” could be removed or 
replaced with “if no error”.

- modify/replace the entire datastore

    Each YANG patch edit specifies one edit operation on the target data
    node.  The set of operations is aligned with the NETCONF edit
    operations, but also includes some new operations.

    +---------------+---------------------------------------------------+
    | Operation     | Description                                       |
    +---------------+---------------------------------------------------+
    | create        | create a new data resource if it does not already |
    |               | exist or error                                    |
    | delete        | delete a data resource if it already exists or    |
    |               | error                                             |
    | insert        | insert a new user-ordered data resource           |
    | merge         | merge the edit value with the target data         |
    |               | resource; create if it does not already exist     |
    | move          | re-order the target data resource                 |
    | replace       | replace the target data resource with the edit    |
    |               | value                                             |
    | remove        | remove a data resource if it already exists or no |
    |               | error                                             |
    +---------------+---------------------------------------------------+

And, in section 2.1

    This can be the
    datastore resource itself, i.e., "{+restconf}/data", or it can be a
    configuration data resource within the datastore resource, e.g.,
    {+restconf/data/ietf-interfaces:interfaces".

[this relates to this email thread "[Netconf] Is a 'replace' operation 
on the candidate datastore always the same as 'remove' + 'merge' ?]
When I look at "replace" above, I'm not sure whether we can 
modify/replace the entire datastore. So basically replacing the entire 
config from a router. */
/*I always thought it was only possible with NETCONF, with the support 
of the :url capability.
So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was 
thinking that "A mechanism to dump and restore configurations is a 
primitive operation needed by operators. Standards for pulling and 
pushing configurations from/to devices are desirable." could only be 
fulfilled with NETCONF.
Now, I'm confused.

- Section 2.2 and 2.3
YANG Tree Diagram For "yang-patch" Container*/
/*s/For/for
YANG Tree Diagram For "yang-patch-status" Container
*//*s/For/for

Not sure yet how/if we should document tree for YANG modules composed of 
groupings only. Currently in discussion with the YANG doctors.

- Section 2.6

    The server will save the running datastore to non-volatile storage if
    it supports non-volatile storage, and if the running datastore
    contents have changed.  This will be done in an implementation-
    specific manner.

You might to add that this is a RESTCONF feature, not a YANG PATCH one.
Indeed, from https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, 
section 3.4

    Each RESTCONF edit of a datastore resource is
    saved to non-volatile storage by the server, if the server supports
    non-volatile storage of configuration data.

What is confusing here is: what does "This will be done in an 
implementation-specific manner." add in draft-ietf-netconf-yang-patch-10 
compared to RESTCONF.
Should this sentence be part of draft-ietf-netconf-restconf, and removed 
from here?

-

leaf comment {
            type string;
            description
              "An arbitrary string provided by the client to describe
               the entire patch.  This value SHOULD be present in any
               audit logging records generated by the server for the
               patch.";

I don't understand why it's not a MUST. Is this because this field is 
optional?
So if it's not in the audit logging, we don't know if it's because the 
field is empty, or because someone decided not to include it.
Do you want to say: If populated, this value MUST be present in any 
audit logging records generated by the server for the patch.

- I'm not clear on the atomicity rules

        container yang-patch {
          description
            "Represents a conceptual sequence of datastore edits,
             called a patch. Each patch is given a client-assigned
             patch identifier. Each edit MUST be applied
             in ascending order, and all edits MUST be applied.
             If any errors occur, then the target datastore MUST NOT
             be changed by the patch operation.

In 
https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4, 
if "edit2" fails, should edit1 be reverted?
If, by patch operation, you mean "leaf operation", then the applied 
change by edit1 should remain, right? If so, if edit2 fails, would edit3 
be applied?
Reading further, I see in section 5:

    If the entire YANG Patch
    request cannot be completed, then no configuration changes to the
    system are done.

Now, I'm confused. An additional example would be useful (only edit2 
fails).
Assuming the sentence in section 5 is right ... Since there are no 
candidate datastores in RESTCONF, is this realistic to "test" edit1, 
edit2, edit3 part of the 
https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4 
in order to populate the potential error message, and to revert the 
command if there is an error message?

And I see this diff between version 8 and 9.

Surprised that, if there is any error, it's not a MUST to return the 
"yang-patch-status" message? Maybe I missed the discussion on the 
mailing list. Feel free to let me know. - Section 5.

    It may be possible to use YANG Patch with other protocols besides
    RESTCONF, which is outside the scope of this document.

Is a repeat from the intro. - Editorial OLD

            case global-errors {
              uses rc:errors;
              description
                "This container will be present if global
                 errors unrelated to a specific edit occurred.";
            }
NEW
            case global-errors {
              uses rc:errors;
              description
                "This container will be present if global
                 errors are unrelated to a specific edit occurred.";
            }

Regards, Benoit (OPS AD)

---

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Jul 2016 09:50:46 +0200

One more point.
The trees in section 2.2 and 2.3 are not correct.

pyang -f tree --tree-print-groupings [email-masked]
module: ietf-yang-patch
groupings:
   yang-patch
      +---- yang-patch
         +---- patch-id?   string
         +---- comment?    string
         +---- edit* [edit-id]
            +---- edit-id?     string
            +---- operation    enumeration
            +---- target       target-resource-offset
            +---- point?       target-resource-offset
            +---- where?       enumeration
            +---- value?

   yang-patch-status
      +---- yang-patch-status
         +---- patch-id?      string
         +---- (global-status)?
         |  +--:(global-errors)
         |  |  +---- errors
         |  |     +---- error*
         |  |        +---- error-type       enumeration
         |  |        +---- error-tag        string
         |  |        +---- error-app-tag?   string
         |  |        +---- error-path?      instance-identifier
         |  |        +---- error-message?   string
         |  |        +---- error-info?
         |  +--:(ok)
         |     +---- ok?            empty
         +---- edit-status
            +---- edit* [edit-id]
               +---- edit-id?   string
               +---- (edit-status-choice)?
                  +--:(ok)
                  |  +---- ok?        empty
                  +--:(errors)
                     +---- errors
                        +---- error*
                           +---- error-type       enumeration
                           +---- error-tag        string
                           +---- error-app-tag?   string
                           +---- error-path? instance-identifier
                           +---- error-message?   string
                           +---- error-info?

Regards, Benoit
> - I see one issue at https://github.com/netconf-wg/yang-patch/issues. 
> Is this integrated?
>
> "Server" according to the terminology section is the RFC6241 
> definition, so server = NETCONF server.
>
> <https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-8>._It has a representation with the media-type 
> "application/yang-data+xml" or "application/yang-data+json"._
>        A data element representing the YANG Patch is sent by the
>     client tospecify the edit operation request.  When used with the
>     HTTP PATCHmethod, this data is identified by the YANG Patch media
>     type.
>
>     Should be yang-patch request or something that someone not
>     familiar with the netconf RPC concept can related to in the HTTP
>     world which this I-D is for.
>
> So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I 
> was thinking that "A mechanism to dump and restore configurations is a 
> Not sure yet how/if we should document tree for YANG modules composed 
> of groupings only. Currently in discussion with the YANG doctors.
>
> - Section 2.6
> Indeed, from 
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, section 3.4
>
> implementation-specific manner." add in 
> draft-ietf-netconf-yang-patch-10 compared to RESTCONF.
> Should this sentence be part of draft-ietf-netconf-restconf, and 
> removed from here?
>
> -
> leaf comment {
>             type string;
>             description
> change by edit1 should remain, right? If so, if edit2 fails, would 
> edit3 be applied?
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 12 Jul 2016 12:40:56 -0700

Jason/Xiang,

Picking up on this particular point that Benoit brought up in his AD review. The two of you went back and forth on the thread that he mentions below and came to a conclusion that one could not replace the entire configuration using <edit-config>. Martin, added a case ##5 which went on to demonstrate that only <copy-config> could be use to replace the entire configuration. Citing specific piece of that e-mail thread:

>> ## Initial server Config A (used in all the cases below):
>>  <system>
>>    <password-control>
>>      <min-length>12</min-length>
>>      <require-caps>true<require-caps>
>>    </password-control>
>>    <console>
>>      <width>132</width>
>>      <enabled>true</enabled>
>>    </console>
>>  </system>
>>  <qos>
>>    <ingress>
>>      <class-limit>8</class-limit>
>>      <sub-classes>true</sub-classes>
>>    </ingress>
>>  </qos>
> 
> 
>> ## Case 4:
>> - Initial Config A
>> - edit-config request (!! with default-operation replace !!):
>>     <system>
>>       <password-control>             
>>         <min-length>10</min-length>  
>>       </password-control>  
>>     </system>
>> - Resulting config on the server (entire server datastore affected ?):
>>     <system>
>>       <password-control>
>>         <min-length>10</min-length>
>>       </password-control>
>>     </system>
>>    // no qos data ?
> 
> This is not correct; qos is unaffected.
> 
> ## Case 5:
> - Initial Config A
> - copy-config request
>    <system>
>       <password-control>             
>         <min-length>10</min-length>  
>      </password-control>  
>     </system>
> - Resulting config on the server (entire server datastore affected !):
>     <system>
>       <password-control>
>        <min-length>10</min-length>
>      </password-control>
>     </system>
>    // no qos data !

> On Jul 11, 2016, at 9:52 AM, Benoit Claise <[email-masked]> wrote:
> 
> [this relates to this email thread "[Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ?]
> When I look at "replace" above, I'm not sure whether we can modify/replace the entire datastore. So basically replacing the entire config from a router. 

Would you agree with Benoit on the above statement?

> I always thought it was only possible with NETCONF, with the support of the :url capability.

With <copy-config> semantics. Right? The question of whether it is limited to NETCONF did not come up.

> So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was thinking that "A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable." could only be fulfilled with NETCONF.
> Now, I'm confused.

Mahesh Jethanandani
[email-masked]

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Tue, 12 Jul 2016 20:16:48 +0000

Hi Mahesh,

I'm not positive what you are asking.

I agree that we concluded that NETCONF <edit-config> can *not* be used to replace or delete an entire datastore.  That is only supported in NETCONF using specific "root level" RPCs (i.e. <copy-config> and <delete-config>).

I'm not familiar enough with RESTCONF or patch to comment on whether those allow a mix of replacing subtrees and/or entire datastores with the same primitive/RPC.  Note that replacing an entire datastore implies that you delete every node of every single data model in the router.  In other words -> if a device supported a mix of proprietary + IETF + OpenConfig models then a "replace at root" (i.e. equivalent of <copy-config>) would have to replace all data in all those namespaces.

Jason

From: Mahesh Jethanandani [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 15:41
To: Sterne, Jason (Nokia - CA); Xiang Li
Cc: [email-masked]; NETCONF; Benoit Claise
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

Jason/Xiang,

## Case 4:
- Initial Config A

## Case 5:
- Initial Config A
- copy-config request
   <system>
      <password-control>

On Jul 11, 2016, at 9:52 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

   |               | exist or error                                    |

   |               | error                                             |

   |               | value                                             |

   |               | error                                             |

   This can be the

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 12 Jul 2016 13:44:37 -0700

Ok. We seem to agree that <edit-config> cannot be used to replace or delete an entire configuration. 

Though the discussion was in the context of NETCONF, I would venture to say the same would apply to RESTCONF and YANG Patch also.

>    {+restconf/data/ietf-interfaces:interfaces".

where we are referencing the entire datastore “{+restconf}/data” seems to imply that the entire data store can be replaced or deleted using edit operations is not correct.

Does anyone disagree?

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 14:08:04 -0700

Hi,

YANG Patch does not replace the entire datastore.
If the target resource is the datastore then each edit target
is relative to the datastore root.

Andy

On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> Though the discussion was in the context of NETCONF, I would venture to
> say the same would apply to RESTCONF and YANG Patch also.
>
> where we are referencing the entire datastore “{+restconf}/data” seems to
> imply that the entire data store can be replaced or deleted using edit
> operations is not correct.
>
> Does anyone disagree?
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
>

---

From: "Steve Truong (struong)" <[email-masked]>
Date: Wed, 13 Jul 2016 03:37:41 +0000

I guess we have to view the document under the concept of patching and patching is never replacing.
But I think there is a need to replace the datastore using restconf, or not?

steve

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, July 12, 2016 2:08 PM
To: Mahesh Jethanandani
Cc: [email-masked]; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

Hi,

Andy

On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:
Ok. We seem to agree that <edit-config> cannot be used to replace or delete an entire configuration.

And, in section 2.1

   This can be the

Does anyone disagree?

Mahesh Jethanandani

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 20:43:13 -0700

> But I think there is a need to replace the datastore using restconf, or

Try:

   PUT /restconf/data

   { "data" : {
       ... entire config
      }
    }

Andy

> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Tuesday, July 12, 2016 2:08 PM
> *To:* Mahesh Jethanandani
> *Cc:* [email-masked]; NETCONF
> *Subject:* Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10
>
>
>
> Hi,
>
>
>

---

From: "Steve Truong (struong)" <[email-masked]>
Date: Wed, 13 Jul 2016 03:46:14 +0000

Thanks Andy for confirming that for datastore replacing we can use the “base” restconf facility.

steve

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 8:43 PM
To: Steve Truong (struong)
Cc: Mahesh Jethanandani; [email-masked]; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

On Tue, Jul 12, 2016 at 8:37 PM, Steve Truong (struong) <[email-masked]<mailto:[email-masked]>> wrote:
I guess we have to view the document under the concept of patching and patching is never replacing.
But I think there is a need to replace the datastore using restconf, or not?

Try:

   PUT /restconf/data

   { "data" : {
       ... entire config
      }
    }

steve

Andy

From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Tuesday, July 12, 2016 2:08 PM
To: Mahesh Jethanandani
Cc: [email-masked]<mailto:[email-masked]>; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

Hi,

Andy

And, in section 2.1

   This can be the

Does anyone disagree?

Mahesh Jethanandani

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2016 10:15:24 -0700

> “base” restconf facility.

Not so fast...

restconf-15, sec 4.5

   The only target resource media type that supports PUT is the data
   resource.  The message-body is expected to contain the content used

       to create or replace the target resource.

I know our server code does not accept a replace-datastore via PUT right
now, but it could.

I support adding text that allows PUT to be used on a datastore resource as
well.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Tuesday, July 12, 2016 8:43 PM
> *To:* Steve Truong (struong)
> *Cc:* Mahesh Jethanandani; [email-masked]; NETCONF

---

From: Benoit Claise <[email-masked]>
Date: Sat, 16 Jul 2016 23:56:10 +0200

Hi Andy,

It would be nice to make it clear.
Maybe I overlooked that statement in the draft.

Regards, B.
> On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Though the discussion was in the context of NETCONF, I would
>     venture to say the same would apply to RESTCONF and YANG Patch also.
>
>     where we are referencing the entire datastore “{+restconf}/data”
>     seems to imply that the entire data store can be replaced or
>     deleted using edit operations is not correct.
>
>     Does anyone disagree?
>
>     Mahesh Jethanandani
>     [email-masked] <mailto:[email-masked]>
>
>
>
>