Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 1 Mar 2015 18:09:56 +0100

On Thu, Feb 26, 2015 at 03:04:26PM +0100, Juergen Schoenwaelder wrote:
> On Thu, Feb 05, 2015 at 01:22:43PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote:
> > Dear NETCONF WG,
> > we hereby issue a WG Last Call for 3 weeks for the drafts below:
> > 
> > https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
> > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03
> > 
> > Please review and send your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT.
> 
> Hi,
> 
> Here is my review of draft-ietf-netconf-restconf-04. Comments come
> roughly in the order of the document. I am running out of time to get
> a review done of draft-ietf-netconf-yang-patch-03 by today's deadline.
> I may get to it by Monday (but no hard promise).
>

And here is my review of draft-ietf-netconf-yang-patch-03...

- I wonder whether the title can be improved; this document does not
  only define a media type, it actually defines a complete datastore
  patch method. Perhaps a more descriptive title can be found?

- The introduction is kind of mis-leading since NETCONF has a method
  to patch a datastore (edit-config). This document is primarily
  written to support RESTCONF I assume. And then the first paragraph
  says "simpler edit request format" - simpler compared to what?

- What is the reason for not defining a NETCONF RPC operation?

- Should it no be 'datastore resource' instead 'datasource resource'
  in 1.1.4?

- Change "1.1.5. Terms" to "1.1.5. YANG Patch"? The whole section 1.1
  is about terminology.

- I did not know how to understand this sentence in section 2 until
  looking up the YANG module:

    The specific fields are defined with
    the 'application/yang.patch' extension definition in the YANG module
    Section 3.

  Perhaps less is more:

    The specific fields are defined in the YANG module in Section 3.

- Again, I find it somewhat strange that the document says how one has
  to define the NETCONF RPC operation (e.g., section 2.1) - why not
  simply define this instead of leaving this out?

- In section 2.3, I again stumbled across " syntax specification is
  defined by the 'application/yang.patch-status' extension statement".
  The statement defining application/yang.patch-status is
  rc:restconf-media-type but the text makes it sound as if
  application/yang.patch-status would be a statement.

- Perhaps some text can be added to 2.2 and 2.3 to briefly outline
  what the various objects do. Some like:

    A YANG patch is optionally identified by a unique patch-id and it
    may have an optional comment.  A patch is an ordered collection of
    edits. Each edit is identified by an edit-id and it has an edit
    operation (create, delete, insert, merge, move, replace, remove)
    that is applied to ...

  I think that in particular target, point, and where may need some
  explanation for a first time reader.

- Why is it useful to have absolute and relative target paths? Would
  it not be simpler if target path would always be absolute that the
  root would always be a datastore? Perhaps it makes sense to have
  both but it is not clear why.

- Should the edit operations not be described using YANG terminology?
  This is supposed to be YANG patch and not RESTCONF patch.

- Why is there an automatic commit to startup? Would this not be
  somewhat surprising from a NETCONF point of view? Can I use YANG
  patch to modify some other datastore, e.g., candidate with NETCONF?
  If so, why would this lead to a copy of running to startup? Perhaps
  this is not the intention but the text is not clear. I am also not
  clear why the text says "after the edits have been attempted" - why
  does the text not require that all edits have been successful?

- If there would be an RPC binding for NETCONF, would I also be able
  to invoke this RPC via RESTCONF if the corresponding module is
  announce? I would assume so - perhaps this does not need
  clarification (just checking).

- Why do we use RESTCONF specific types in the YANG module? Why not be
  protocol agnostic by using instance-identifier instead of
  target-resource-offset? I also do not know where "Data Resource
  Identifier" is defined and as such target-resource-offset is under
  specified (and "offset" may be misleading people, no?).

- What about the TBDs in sections 4.2 and 4.3?

- How can the error objects use RESTCONF specific definitions if we claim
  that this would also work with NETCONF?

- The description of yang-patch says on error the datastore MUST NOT
  be changed while previously the text said "SHOULD be returned to its
  original state".

- I do not understand this:

            A patch MUST be validated by the server to be a
            well-formed message before any of the patch edits
            are validated or attempted.

  Where is it detailed how an implementation has to validate a patch
  edit? While applying a sequence of edits, things may temporarily not
  validate. Does this matter? Why not simply require that the
  datastore must be valid if the complete patch succeeds and if
  validation fails after all edits have been applied, then this is
  reported? That is, validate the result obtained after applying all
  all edits but not all intermediate steps.

- Why is the comment restricted to 1024 characters? Seems like an
  arbitrary restriction.

- The description of the operation enumeration is less RESTCONF
  specific but it still talks about data resources, which I think it
  should not. Same for target and other leafs.

- It is not entirely clear whether say a move moves the data node
  identified by point + where to the target or whether it moves the
  target to point + where.

- The usage of anyxml seems under-specified. It is non-interoperable
  using the JSON encoding document (which is not even referenced from
  this document - even though we have several examples with JSON
  encoding - but for this anyxml usage, we need some normative text
  that clearly says how anyxml is encoded). This actually seems to be
  a usage of anydata.

- What about putting the ok leaf into an explicit case? Might be
  easier to read.

- Why is edit-id numeric in some of JSON examples? The YANG model says
  it is a string. Lada would throw an error on this...

/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: Phil Shafer <[email-masked]>
Date: Sun, 1 Mar 2015 13:39:09 -0500

>  says "simpler edit request format" - simpler compared to what?

This is my big issue with yang-patch: Why can't this be done using
edit-config?  What does yang-patch add that can't be performed with
edit-config?  Does restconf not expose an edit-config operation?
What's the value of inventing a second way of doing config edits?
How does a second way help us in advancing standardized network
management operations?  Are there sufficient benefits with yang-patch
to justify the expense, churn, duplication, and confusion it will
bring?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Mar 2015 18:31:37 -0800

> to justify the expense, churn, duplication, and confusion it will

RESTCONF edit operations are done on data resources.
NETCONF <edit-config> is not resource-oriented.

YANG Patch edits are ordered.
NETCONF <edit-config> order (and whether or not a real
edit is invoked) is implementation-dependent.

YANG Patch might allow edits to be encoded more efficiently
since the config 'scaffolding' is not part of the each edit.
Operations such as 'move' are explicit and more efficient
to encode than YANG insert.

>  Phil

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Mar 2015 22:46:02 -0500

>to encode than YANG insert.

That's a really short list, and it looks like the first and last
are the same (since "data resource" means a path into a datastore,
right?).

Encoding efficiency aside, what's the big innovation in yang-patch?
If it's really just putting multiple change payloads in a single
request such that any of them can fail independently, aren't we
better served by adding this to edit-config, perhaps as a sister
attribute to "op"?

Thanks,
 Phil

P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Mar 2015 23:56:39 -0800

> better served by adding this to edit-config, perhaps as a sister

What is so great about the implementation-dependent <config> blob?
Why are a set of attributes (1 in NETCONF, the rest defined in YANG)
better than an edit list?

I have heard some comments that the patch approach is more direct
and easier for the client to convey its intent.  A set of ordered edits
provides more client control for setting up dependencies.

IMO the NETCONF encoding of an edit is irrelevant to RESTCONF.
RESTCONF does not use an <rpc> element wrapper for operations
either. Most (if not all) of the message encoding details are different.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Mar 2015 09:12:21 +0100 (CET)

> better than an edit list?

To be fair, I think Phil is right in that the expressiveness of both
formats are equal.  Which one you prefer is subjective, possibly
influenced by implementation choices.

The question boils down to if we think it is good to have two more or
less equal ways of doing things, or if there is value in having one
single mechanism.

> provides more client control for setting up dependencies.

Even with YANG PATCH, it is the resulting datastore that is validated,
so the order of the edits doesn't matter.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Mar 2015 06:16:04 -0800

> influenced by implementation choices.

I think I could find examples where the patch XML was shorter
than the <config> XML.  IMO there very few interoperability
ambiguities with an edit list approach.  I bet there are differences
in the way servers handle nested operation/insert attributes.
Embedding the actions in the data is not equivalent.

> less equal ways of doing things, or if there is value in having one

But we are not creating NETCONF over HTTP.
RESTCONF is a different protocol than NETCONF.
I don't understand why the message encoding should
be the same for this subset of NETCONF functionality.

Andy

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Tue, 3 Mar 2015 20:54:42 +0000

All,

it seems that we had only one serious review of the Restconf and YANG patch drafts so far.
This is not sufficient for drafts with such substantial content.

To be able to call the WGLC successful we need more detailed reviews.

Please continue reviewing and commenting on the Restconf/YANG Patch drafts.

Thank you.

Mehmet 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of ext Juergen Schoenwaelder
Sent: Thursday, February 26, 2015 3:04 PM
To: [email-masked]
Subject: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04

Hi,

/js

- I suggest to follow RFC 6020 and use 'RPC operations' instead of
  'protocol operations' but then I note that RFC 6241 uses 'protocol
  operations'. Too bad that we are not consistent. (Should we try to
  settle on a single term? Perhaps we should fix this in YANG 1.1?)

- I suggest to use 'event notifications' instead of 'notification
  events'. The model, I think, is that event occurs that leads to a
  notification. I later parts of the document the term 'event
  notification' is actually used.

- What exactly is the 'framework' and in particular the 'meta-model'
  referred to in section 1.1? I do not understand the 'instead' -
  instead of what?

- The document talks about API resources pretty early but it is
  somewhat unclear what API resources are. Even section 3.3 is leaving
  me as an almost first time reader somewhat confused. Why is this
  thing called an API resource? Section 3.3 makes me believe this is
  simply a top-level container for data and operations (not sure where
  the other resources hang in the URI space or why they are not API
  resources).

- What does it meant that "configuration persistence are handled by
  the server and not controlled by the client." Is this trying to tell
  me that the client has no way of knowing whether any config changes
  persist? If so, is this useful? Or is the idea that all edits will
  eventually persist but not necessarily immediately, which seems to
  be what the last paragraph in 3.4 hints at. I am also unsure what
  this means: "There is no guarantee [...] that the saved
  configuration is always a mirror of the NETCONF running datastore,
  if the server also supports NETCONF." What is a NETCONF/RESTCONF
  server that supports #startup doing if edits are received via both
  NETCONF and RESTCONF? Perhaps there is a need to factor all this out
  into a separate section discussing NETCONF/RESTCONF coexistence. I
  think there are additional things to discuss, e.g. that a combined
  server also MUST maintain NETCONF last change time stamps, no?

- It often reads as if there can be multiple datastore resources but
  then at other places it seems there is only one datastore resource,
  namely {+restconf}/data. (I am wondering why this is actually a good
  idea, why do we not have {+restconf}/running plus optionally
  {+restconf}/startup? I can understand why exposing candidate may not
  be useful, but saying there is {+restconf}/data and it magically
  interacts with NETCONF's running and startup datastores makes it
  difficult for me to understand what is going on. If the goal is to
  not expose startup, then why not {+restconf}/running? How does
  {+restconf}/data different from NETCONF's running?

- I am not sure I fully understand how key values are encoded in
  corner cases where the value includes characters that conflict with
  the format. What exactly is 'a quoted or unquoted empty string'?
  Which quoting rules apply? And is the syntax defined in section
  3.5.1 the syntax before or after URI pct-encoding? I guess this is
  before pct-encoding, no? I think this encoding needs additional
  clarification and perhaps some examples showing how clashes are
  handled.

- It seems section 3.6 says operation resources only need a module
  name if the server supports operations with conflicting names. I
  think this makes interoperability actually more complex. I would
  prefer is both top-level data resources as well as operations
  resources require to use a module name.

- In section 3.6, why is sending a body a MAY if the "rpc" statement
  defines either input or output? Should this not be a MUST?

- Since XML is the default to implement encoding, would it make sense
  to show the examples in XML instead of JSON? Or show them in both
  encodings? (A few examples, e.g. section 4.6, do show both.)

- Perhaps add 'module example-ops { ... }' around the examples in
  sections 3.6.1 and 3.6.2 so that it is clear where example-ops is
  coming from.

- The example insection 3.7 seems to use the data model defined in
  draft-ietf-netconf-yang-library-00.txt. I think there should be an
  explicit reference to it (and this needs to be consistent with the
  above mentioned I-D).

- Section 4.5 says that data resources can be created using PUT, which
  is slightly at odds with Table 1.

- Section 4.2 and following sections refer to an "entry point
  component". Is this the same as "entry point" or something
  different? I am not sure what it is. Should this term be defined in
  the terminology or can we replace it with something already defined?

- Section 4.3, when do I return 403 and when 404 or can I choose
  between these error responses as I like? This seems to also apply
  to subsequent sections.

- The line wrapping in the table in section 4.8.1 is unfortunate since
  it makes with-defaults to read as two separate entries.

- Section 4.8 is about query parameters but then it section 4.8.1 and
  subsequent sections discuss restconf capabilities that are not query
  parameters. I found this a bit confusing and perhaps the document
  structure should be changed to avoid discussing general protocol
  capabilities where a reader expects a discussion of query
  parameters. When discussing (protocol) capabilities, it may be
  useful to mention how they can be retrieved.

- In section 4.8.4, I am not sure yet how nest levels are counted. If
  I request {+restconf}/data/foo which contains the child bar, is the
  child bar at nest level 2 or 1? An explicit example might help.

- Should the "insert" and "point" parameters not be required to
  implement? If they are optional, then adding something to a list or
  leaf-list ordered by user will be impossible, no?

- For the notification examples, would it make sense to provide an
  outline of the the corresponding YANG definition, e.g,

  module example-mod {
    namespace "http://example.com/event/1.0";

    notification event {
     leaf event-class { type string; }
     container reporting-entity {
       leaf card { type string; }
     }
     leaf severity { type string; }
    }
  }

  Did I get this right? Not sure this is the best example. Perhaps we
  should consider using already RFC published data model snippets as
  examples instead of mock-up examples. Well, this already leads to
  another question. Does netconf-config-change (RFC 6470) makes sense
  for RESTCONF? If so, how to fill in the details? So perhaps these
  notifications do only apply to a NETCONF server but not to a
  RESTCONF server. So do we have similar definitions for RESTCONF?

- Looking at the tree diagram of the ietf-restconf-monitoring module,
  I was wondering whether

               +--ro encoding* [type]
                  +--ro type      string
                  +--ro events    inet:uri

   should not be better named

               +--ro access* [encoding]
                  +--ro encoding  string
                  +--ro location  inet:uri

- I am also wondering whether ietf-restconf-monitoring is really the
  right module name. It defines objects to obtain the restconf
  capabilities and to find access points for the notification streams,
  this is not exactly monitoring. Perhaps -monitoring was a not so
  good choice back then and we now stay with it for consistency...

  Anyway, should there be explicit text that restconf capabilities
  must not show up in ietf-netconf-monitoring and that the counters in
  ietf-netconf-monitoring will not be bumped by restconf interactions?
  Perhaps this also belongs into a section discussing NETCONF/RESTCONF
  coexistance issues, see above.

- Section 10 normatively depends on draft-ietf-netconf-yang-library
  (as correctly stated in 14.1 - there are acutally quite a few things
  that we need to finish up in order to publish this document). I am
  not sure, though, that [rest-dissertation] really is
  normative. [XPATH] on the other hand seems to be normative rather
  than informative (see the filter option).

- Several TBD in 11.3 probably need to be filled in.

- For creating a RESTCONF Capability Registry (section 11.4), it will
  be necessary to specify the rules IANA should use to handle the
  registry.

- In section 12, I do not understand what is meant with this:

      Implementors SHOULD provide a comprehensive
      authorization scheme with RESTCONF and ensure that the resulting
      NETCONF username is made available to the RESTCONF server.

  Is this authorization or authentication? And what does
  "comprehensive" translate to?

  What does "SHOULD be implemented carefully with adequate attention
  to all manner of attack one might expect to experience with other
  management interfaces." mean? Do you mean 'implemented' or
  'deployed'?

- In the jukebox YANG module (I understand it is only an example), I
  am somewhat concerned to see rc:data-resource-identifier. This kind
  of sends the signal that it is OK to write RESTCONF specific YANG
  data models. Frankly, if the end result is that we get RESTCONF and
  NETCONF specific data models, then perhaps we should not even do
  RESTCONF in the first place. I do understand the value of having a
  REST interface but I am also very much concerned if data models
  become either NETCONF or RESTCONF specific.

- I have not reviewed the examples in appendix D.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Mar 2015 15:35:40 -0800

On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund <[email-masked]> wrote:
> "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:
>> Dear NETCONF WG,
> I have mentioned this before, but I don't think it has been resolved
> yet - the usage of anyxml in the patch document needs more work.
> Together with the latest json draft, the anyxml usage is
> underspecified, and will not be interoperable.
>

I think the draft is clear how to encode YANG data nodes
within the "value" anyxml node.  The problem is if the
data node pointed at by "target" (or its descendants)
is an anyxml node.

IMO Phil's string leaf encoding of the web-banner applies to
XML as well as JSON when the content is any XML.
The anyxml node is supposed to be a terminal
(i.e., it can only be edited or retrieved as a whole).
It cannot be a terminal and also (sometimes) have child nodes.

This is the difference between anyxml and anydata.

The "anyxml" node is any XML.
It is a terminal. It never has any child nodes.
Any nested XML elements are just part of the terminal node,
not child data nodes.

The "anydata" node is an arbitrary YANG data subtree.

Anyxml usage such as "root" and other containers are useful hacks,
but they are really expecting any data, not any XML.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Mar 2015 14:34:31 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> within the "value" anyxml node.

I don't understand this.

Assume we have:

  container servers {
    list server {
      key name;
      leaf name { type string; }
      container address {
        leaf ip { type inet:ip-address; }
        leaf port { type inet:port-number; }
      }
    }
  }

Now I want to set address/port and enabled in a given server
instance.

In XML I would do:

  PATCH /restconf/data/my-module:servers/server=srv1

  <yang-patch xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-patch">
    <edit>
      <edit-id>1</edit-id>
      <operation>merge</operation>
      <target>.</target>
      <value>
        <server xmlns="http://example.com/my-module">
          <name>srv1</name>
          <address>
            <port>42</port>
          </address>
          <enabled>true</enabled>
        </server>
      </value>
    </edit>
  </yang-patch>

Now, I want to do this in JSON.

First of all I just noticed that YANG PATCH is missing a reference to
draft-ietf-netmod-yang-json.

Anyway, there is no special text in YANG PATCH about json encoding, so
I assume that the rules defined in draft-ietf-netmod-yang-json
applies.

"value" is of type anyxml, so I look at draft-ietf-netmod-yang-json to
see what it says about "anyxml":

   An anyxml instance is encoded as a name/value pair.  The value can
   be of any valid JSON type, i.e. an object, array, number, string or
   one of the literals "true", "false" and "null".

So maybe I do:

 "value": [ "server": { "name": "srv1",
                        "address": { "port": 42 }
                        "enabled": "true"
                      } ]

This seems to be valid according to draft-ietf-netmod-yang-json.  Will
all servers understand it?

> The problem is if the

If the leaf is of type "string", and contains a web-banner, there is
no problem.

> (i.e., it can only be edited or retrieved as a whole).

Yes.

> The "anydata" node is an arbitrary YANG data subtree.

No, I think that "anydata" should also be treated as a terminal node.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 4 Mar 2015 15:13:21 +0100

> On 04 Mar 2015, at 14:34, Martin Bjorklund <[email-masked]> wrote:
> 

IMO this is not automatic and the description of “anyxml value” should explicitly state that the value must be an instance of a container whose schema is determined by the sibling “target” leaf, and that its encoding in XML and JSON must follow the rules of RFC 6020 and draft-ietf-netmod-yang-json, respectively.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Mar 2015 06:53:49 -0800

> IMO this is not automatic and the description of “anyxml value” should explicitly state that the value must be an instance of a container whose schema is determined by the sibling “target” leaf, an…

It does say that.
I don't really see any consensus forming wrt/ anyxml or anydata.
Perhaps it is time to declare the issue dead.
If a vendor really wants to store raw XML in their config,
they will figure out a way to do that.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Mar 2015 15:58:30 +0100

> they will figure out a way to do that.

No, there is nothing about JSON I can find.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Mar 2015 13:35:50 -0700

>                         "address": { "port": 42 }

I tried an online XML to JSON converter:

{
  "yang-patch": {
    "-xmlns": "urn:ietf:params:xml:ns:yang:ietf-yang-patch",
    "edit": {
      "edit-id": "1",
      "operation": "merge",
      "target": ".",
      "value": {
        "server": {
          "-xmlns": "http://example.com/my-module",
          "name": "srv1",
          "address": { "port": "42" },
          "enabled": "true"
        }
      }
    }
  }
}

Whether object or array-of-1 is used is not that interesting.
A parser should handle both.

> If the leaf is of type "string", and contains a web-banner, there is

It needs to be a string to contain mixed XML on most (if not all)
implementations in the wild.

> No, I think that "anydata" should also be treated as a terminal node.

So we still need use-specific description-stmts to
completely define the intent and constraints
when applying a schema-specific object template?
(NETCONF <config>, <data>, <filter>, etc.)

It seems like we are ignoring the real use-cases and focusing on
converting mixed mode XML to JSON. IMO, not very important,
but just make sure we do not ruin the solution for the 98% use-cases.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Mar 2015 14:02:24 -0700

> less equal ways of doing things, or if there is value in having one

This is an important issue to decide because starting over on
the multiple-edits-per-PATCH problem will take awhile.

My motivations for writing YANG Patch, instead of using
the <config> blob approach:

  1) RESTCONF is supposed to be resource oriented.
      Patching resources vs. patching the entire <config>
      is an architectural distinction, but that matters to some people

  2) <config> patch relies on meta-data encoded as XML attributes.
      The JSON attributes solution requires much more server resources.
      I'm not sure there is a CBOR attributes solution for CoMI.
      A solution that does not need meta-data peppered throughout
      the message will be more encoding-neutral.

  3) There are some corner-cases (e.g., nested operation attributes,
       duplicate sub-trees in the edit-config, edit ordering) that
       are very implementation-dependent.  It is possible that an
       ordered edit list will increase predictable server processing of
       edits, but I agree this is just an assumption on my part.

 4) The implementation requirements for <edit-config> are not
      that clear in RFC 6241.  I have seen some server limitations
      that are never mentioned in the RFC, like inability to create
      multiple list entries at once.  The yang-patch-status response message
      is more granular than <rpc-error>, which could allow better
      error messages for implementation-specific error conditions.

I am not 100% opposed to starting over on YANG Patch,
but the solution "just use <edit-config> is not good enough.

Andy