Subject: [Netconf] YANG patch with XML and Netconf edit-config

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Sat, 26 Sep 2015 03:25:08 +0000

Helo Andy, Martin, Kent,

looking at draft-ietf-netconf-yang-patch-05, I am wondering if you have examples for YANG-patch with XML encoding.  The examples in section D are all JSON-encoded.

I am wondering specifically about how the XML encoding in YANG-patch relates to the Netconf encoding of edit-config.  I was hoping the two would be aligned or even the same, but is this the case?  It seems that the yang-patch way of doing things will require a different encoding of the payload, meaning you cannot simply take the same "edit snippet" and use it both for Netconf and Restconf, instead the content/encoding will depend on the underlying transport, not be agnostic to it.  Is this understanding correct?  What is the intention?  Do we have some examples?

For example, if we have (per the example in RFC 6241) the following edit-config snippet:

       <edit-config>

         <target>

           <running/>

         </target>

         <default-operation>none</default-operation>

         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

           <top xmlns="http://example.com/schema/1.2/config">

             <interface xc:operation="delete">

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

       </edit-config>

what does the corresponding YANG-patch look like - something like this:  (edit-config style)

      Accept: application/yang.patch-status+xml

      Content-Type: application/yang.patch+xml

      <yang-patch>

        <patch-id>my-patch</patch-id>

        <edit>

         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

           <top xmlns="http://example.com/schema/1.2/config">

             <interface xc:operation="delete">

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

        </edit>

       </yang-patch>

or is it something like this:

      Accept: application/yang.patch-status+xml

      Content-Type: application/yang.patch+xml

      <yang-patch>

        <patch-id>my-patch</patch-id>

        <edit>

          <edit-id>edit1</edit-id>

          <operation>delete</operation>

          <target>

             <interface>

               <name>Ethernet0/0</name>

             </interface>

          </target>

         </edit>

       </yang-patch>

Thanks
--- Alex

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2015 21:33:58 -0700

On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (alex) <[email-masked]>
wrote:

> Helo Andy, Martin, Kent,
>
>
>
> looking at draft-ietf-netconf-yang-patch-05, I am wondering if you have
> examples for YANG-patch with XML encoding.  The examples in section D are
> all JSON-encoded.
>
>
>
> I am wondering specifically about how the XML encoding in YANG-patch
> relates to the Netconf encoding of edit-config.  I was hoping the two would
> be aligned or even the same, but is this the case?  It seems that the
> yang-patch way of doing things will require a different encoding of the
> payload, meaning you cannot simply take the same “edit snippet” and use it
> both for Netconf and Restconf, instead the content/encoding will depend on
> the underlying transport, not be agnostic to it.  Is this understanding
> correct?  What is the intention?  Do we have some examples?
>
>
>

Why would it be the same as <edit-config> just because it is encoded in XML?
Why would the data model change because it was XML vs. JSON?

If you want to use edit-config and the server supports it through RESTCONF:

   POST /restconf/operations/edit-config

  <input>
     <target> ... </target>
     <config>
       ...
     </config>
  </input>

Otherwise just use NETCONF if you want to use <edit-config>

Andy

> what does the corresponding YANG-patch look like – something like this:
> (edit-config style)
>
>
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 28 Sep 2015 18:28:44 +0000

Hi Andy,

thank you for your response.

So, the encoding is like in the second alternative – e.g. something like

      <yang-patch>

        <edit>

          <edit-id>edit1</edit-id>

          <target>

             <interface>

               <name>Ethernet0/0</name>

             </interface>

          </target>

         </edit>

       </yang-patch>

(It would still be good to add an example to the appendix in the next revision of the draft.)  So, clearly different from what you have in an edit-config.

My reason for asking was that it seems you could accomplish essentially the same through either a yang-patch, or through an edit-config.  If that’s the case, I was wondering if the way those operations are encoded in XML be aligned?    (Clearly, the data model is the same.)

Thanks
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, September 25, 2015 9:34 PM
To: Alexander Clemm (alex) <[email-masked]>
Cc: Martin Bjorklund (mbjorklu) <[email-masked]>; Kent Watsen <[email-masked]>; Netconf <[email-masked]>
Subject: Re: YANG patch with XML and Netconf edit-config

On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>> wrote:
Helo Andy, Martin, Kent,

I am wondering specifically about how the XML encoding in YANG-patch relates to the Netconf encoding of edit-config.  I was hoping the two would be aligned or even the same, but is this the case?  It seems that the yang-patch way of doing things will require a different encoding of the payload, meaning you cannot simply take the same “edit snippet” and use it both for Netconf and Restconf, instead the content/encoding will depend on the underlying transport, not be agnostic to it.  Is this understanding correct?  What is the intention?  Do we have some examples?

  <input>
     <target> ... </target>
     <config>
       ...
     </config>
  </input>

Andy

       <edit-config>

         <target>

           <running/>

         </target>

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

       </edit-config>

what does the corresponding YANG-patch look like – something like this:  (edit-config style)

      <yang-patch>

        <edit>

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

        </edit>

       </yang-patch>

      <yang-patch>

        <edit>

          <edit-id>edit1</edit-id>

          <target>

             <interface>

               <name>Ethernet0/0</name>

             </interface>

          </target>

         </edit>

       </yang-patch>

Thanks
--- Alex

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2015 11:46:41 -0700

On Mon, Sep 28, 2015 at 11:28 AM, Alexander Clemm (alex) <[email-masked]>
wrote:

> So, the encoding is like in the second alternative – e.g. something like      '
>
>

It follows the schema in ietf-yang-patch.yang

> (It would still be good to add an example to the appendix in the next
> revision of the draft.)  So, clearly different from what you have in an
> edit-config.
>
>
>
> My reason for asking was that it seems you could accomplish essentially
> the same through either a yang-patch, or through an edit-config.  If that’s
> the case, I was wondering if the way those operations are encoded in XML be
> aligned?    (Clearly, the data model is the same.)
>
>
>

There are examples in YANG Patch, appendix D.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Friday, September 25, 2015 9:34 PM
> *To:* Alexander Clemm (alex) <[email-masked]>
> *Cc:* Martin Bjorklund (mbjorklu) <[email-masked]>; Kent Watsen <
> [email-masked]>; Netconf <[email-masked]>
> *Subject:* Re: YANG patch with XML and Netconf edit-config
>
>
>
>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Sep 2015 20:46:47 +0200

> My reason for asking was that it seems you could accomplish essentially the same through either a yang-patch, or through an edit-config.  If that’s the case, I was wondering if the way those operat…

While yang-patch and edit-config can functionally do the same, they
have little in common how they work and this is by design and not by
accident.

I personally think that having yang-patch (not sure I like the name
but I do not have a better proposal) defined so that it is works with
both RESTCONF and NETCONF would be desirable. It is not clear to me
how the configuration datastore, the so called target datastore, is
selected.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2015 12:03:39 -0700

> how the configuration datastore, the so called target datastore, is

https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-02#section-2.2

As you can see from the module structure:
http://www.netconfcentral.org/modulereport/ietf-yang-patch

YANG patch has an edit list.  The 'target' within each edit is a path-expr
relative to the target resource specified in the request URL.

(In our implementation we have found it useful to set the target resource
URI to
the datastore root, and set the 'target' leaf to the full path. The missing
target URI
in the structure has been a problem because it is RESTCONF-specific.)

YANG Patch is being used (already) in several ways.
It also serves as a notification suitable for pub/sub synching.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 28 Sep 2015 19:05:22 +0000

Hi Andy,

thanks.

The examples in YANG Patch appendix D are all JSON, not XML.  But you answered my question.

--- Alex

Sent: Monday, September 28, 2015 11:47 AM

On Mon, Sep 28, 2015 at 11:28 AM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

      <yang-patch>

        <edit>

          <edit-id>edit1</edit-id>

          <target>

             <interface>

               <name>Ethernet0/0</name>

             </interface>

          </target>

         </edit>

       </yang-patch>

Thanks
--- Alex

Andy

From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, September 25, 2015 9:34 PM
To: Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund (mbjorklu) <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>; Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: YANG patch with XML and Netconf edit-config

  <input>
     <target> ... </target>
     <config>
       ...
     </config>
  </input>

Andy

       <edit-config>

         <target>

           <running/>

         </target>

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

       </edit-config>

      <yang-patch>

        <edit>

               <name>Ethernet0/0</name>

             </interface>

           </top>

         </config>

        </edit>

       </yang-patch>

      <yang-patch>

        <edit>

          <edit-id>edit1</edit-id>

          <target>

             <interface>

               <name>Ethernet0/0</name>

             </interface>

          </target>

         </edit>

       </yang-patch>

Thanks
--- Alex

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Sep 2015 10:56:34 -0400

>have little in common how they work and this is by design and not by

Which bring up my question:  what's the point of having both?  Why
do we need two mechanisms for doing the same work?  What's the key
missing feature that yang-patch adds?  Can it be added to edit-config?

When does a user need edit-config versus yang-patch?  There's not
been a clear answer and there's no discussion of this issue in the
current draft.

>how the configuration datastore, the so called target datastore, is

Re: name: yes, it's confusing, since it's not patch(1) and doesn't
patch YANG.  I'd suggest "change-config" as an alternative.

Thanks,
 Phil

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Sep 2015 17:17:43 +0200

> patch YANG.  I'd suggest "change-config" as an alternative.

The name means something in the REST world.
See RFC 5789.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Sep 2015 09:20:43 -0700

> missing feature that yang-patch adds?  Can it be added to edit-config?

The <config> element in <edit-config> or <copy-config> has a few problems
that
YANG Patch solves

  1) edit ordering: there is none in NETCONF.  Completely up to the
      implementation what order edits are processed.  The 'stop-on-error'
      mode of editing should be avoided, since "the first error" can be
different
      on every server.

  2) edit identification:  In NETCONF an explicit edit may be a no-op and
       get ignored, and implicit edits (via the inherited default operation)
       may be a real edit and get invoked.  With an edit-list, the client is
       clearly identifying the requested edits.

  3) reliance on attributes: XML attributes like "operation", "insert",
"key"
      are used to sprinkle the operations in with the data.  Operations
      such as "move" are not obvious at all.  New operations like "rename"
      or "delete-all" are hard to add.  YANG Patch clearly identifies the
edit
     operations without using attributes.

> been a clear answer and there's no discussion of this issue in the

It's the same debate "when to use NETCONF instead of RESTCONF".

The WG consensus has been that RESTCONF should not be a mirror
of NETCONF.  It is not intended to replace NETCONF.  It is up to developers
to decide if RESTCONF is a better fit for their needs. (E.g., maybe
the developer prefers the 10-step complex editing in NETCONF because
it allows long-lived locks -- maybe a simple app developer wants a 1-step
editing
process that does not require locking).

> patch YANG.  I'd suggest "change-config" as an alternative.
It is media type for use with HTTP PATCH.
It patches YANG data resources.

Thanks,

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>