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

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi,
> 
> This errata seems correct.
> 
> 
> Andy
> 
> 
> 
> 
> On Mon, Jun 11, 2018 at 8:37 AM, RFC Errata System <[e-mail] <mailto:[e-mail]>> 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 <http://www.rfc-editor.org/errata/eid5388>
> 
> --------------------------------------
> Type: Technical
> Reported by: Jonathan Hansford <[e-mail] <mailto:[e-mail]>>
> 
> 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
> 

Mahesh Jethanandani
[e-mail]