Subject: [Netconf] [Technical Errata Reported] RFC6241 (5388)

From: RFC Errata System <[email-masked]>
Date: Mon, 11 Jun 2018 08:37:45 -0700 (PDT)

The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5388

--------------------------------------
Type: Technical
Reported by: Jonathan Hansford <[email-masked]>

Section: 8.3.4.2

Original Text
-------------
8.3.4.2.  <discard-changes>

   If the client decides that the candidate configuration is not to be
   committed, the <discard-changes> operation can be used to revert the
   candidate configuration to the current running configuration.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <discard-changes/>
     </rpc>

   This operation discards any uncommitted changes by resetting the
   candidate configuration with the content of the running
   configuration.

Corrected Text
--------------
8.3.4.2.  <discard-changes>

   Description:

         If the client decides that the candidate configuration is not
         to be committed, the <discard-changes> operation can be used to
         revert the candidate configuration to the current running
         configuration.

         This operation discards any uncommitted changes by resetting
         the candidate configuration with the content of the running
         configuration.

   Positive Response:

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

   Negative Response:

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <discard-changes/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Notes
-----
RFC 6241 section 1.1 includes the following two definitions:

   o  protocol operation: A specific remote procedure call, as used
      within the NETCONF protocol.

   o  remote procedure call (RPC): Realized by exchanging <rpc> and
      <rpc-reply> messages.

Positive and negative responses are detailed for all instances of an operation within the RFC with the exception of <discard-changes>.

Section 8.3.4.2 identifies <discard-changes> as an operation, and appendices A and C identify "rollback-failed" as an error-tag to be used when the "Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason."

This change clarifies that <discard-changes> requires an <rpc-reply>.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title               : Network Configuration Protocol (NETCONF)
Publication Date    : June 2011
Author(s)           : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jun 2018 10:19:06 -0700

Hi,

This errata seems correct.

Andy

On Mon, Jun 11, 2018 at 8:37 AM, RFC Errata System <
[email-masked]> wrote:

> Positive and negative responses are detailed for all instances of an
> operation within the RFC with the exception of <discard-changes>.
>
> Section 8.3.4.2 identifies <discard-changes> as an operation, and
> appendices A and C identify "rollback-failed" as an error-tag to be used
> when the "Request to roll back some configuration change (via
> rollback-on-error or <discard-changes> operations) was not completed for
> some reason."
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Jun 2018 21:10:06 +0000

Seems okay to me too.

/kw

On 6/11/18, 1:19 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

On Mon, Jun 11, 2018 at 8:37 AM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5388<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_errata_eid5388&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=qiHjWg8bIrIM3jM2fqOb_mNHU4dbqcfnQnvOD5fcntQ&s=tFIRijX-PbLD3apJUCoGk77LizpT1jH4jPVsD7ZH8N8&e=>

--------------------------------------
Type: Technical
Reported by: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>

Section: 8.3.4.2

Original Text
-------------

     <rpc message-id="101"

Corrected Text
--------------

   Description:

   Positive Response:

   Negative Response:

   Example:

     <rpc message-id="101"

Notes
-----

Instructions:
-------------

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 13 Jun 2018 09:18:37 -0400

If we agree, would it make sense to have the example for the error case, complete with error code?

> On Jun 11, 2018, at 1:19 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> On Mon, Jun 11, 2018 at 8:37 AM, RFC Errata System <[email-masked] <mailto:[email-masked]>> wrote:
> http://www.rfc-editor.org/errata/eid5388 <http://www.rfc-editor.org/errata/eid5388>
> 
> Reported by: Jonathan Hansford <[email-masked] <mailto:[email-masked]>>
> 
> Section: 8.3.4.2
> 
> Original Text
> -------------

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Jun 2018 21:26:11 +0000

I don't think this is necessary.  Of all the other operations, only the <lock> operation has an example of an <rpc-error>, and I think this is because its "Negative Response" definition specifies special behavior, unlike any other operation.

Kent

On 6/13/18, 9:18 AM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 11, 2018, at 1:19 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5388<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_errata_eid5388&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=IoOnJwsGznMWFbTKq0w2QLI7LZzslibbCMX_gEK2v9M&s=dunte0ooPA7WCzsMj4BzH4I3zn9CMYswfjBHH6HIpd8&e=>

Section: 8.3.4.2

Original Text
-------------

     <rpc message-id="101"

Corrected Text
--------------

   Description:

   Positive Response:

   Negative Response:

   Example:

     <rpc message-id="101"

Notes
-----

Instructions:
-------------

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