Re: [netconf] [Editorial Errata Reported] RFC8650 (7400)

[CC-ing Authors, who should reply to an errata posted against their document.]

I agree with Chris that the Errata is more than Editorial.

Comments:

1) This Errata suggests two mutually-exclusive options: NEW1 and NEW2.  IDK if an errata can contain options.  AFAIK, either the whole errata is accepted or rejected.

2) As for NEW1, this seems correct, though the impact is negligible, given that the examples being corrected are in a non-normative Appendix.

3) As for NEW2, this seems incorrect.  The text in RFC 8040 only applies to RFC 8040.  Other documents wishing to do the same most declare that intention themselves.  Of course, we'd hope that such documents would use RFC 8792 that, obviously, came out after RFC 8040.  But again, these examples are in a non-normative Appendix.

Kent // co-chair

> On Apr 27, 2023, at 7:52 PM, Chris Smiley <csmiley@amsl.com> wrote:
> 
> 
> Hi Rob,
> 
> We are unable to verify this erratum that the submitter marked as editorial. 
> Please note that we have changed the “Type” of the following errata 
> report to “Technical”. As Stream Approver, please review and set the 
> Status and Type accordingly (see the definitions at 
> https://www.rfc-editor.org/errata-definitions/).
> 
> You may review the report at: 
> https://www.rfc-editor.org/errata/eid7400
> 
> Please see https://www.rfc-editor.org/how-to-verify/ for further 
> information on how to verify errata reports.
> 
> Further information on errata can be found at: 
> https://www.rfc-editor.org/errata.php.
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
>> On Mar 21, 2023, at 12:48 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>> 
>> The following errata report has been submitted for RFC8650,
>> "Dynamic Subscription to YANG Events and Datastores over RESTCONF".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7400
>> 
>> --------------------------------------
>> Type: Editorial
>> Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
>> 
>> Section: A.3
>> 
>> Original Text
>> -------------
>>  POST /restconf/operations
>>       /ietf-subscribed-notifications:establish-subscription
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-xpath-filter":
>>          "/ietf-vrrp:vrrp-protocol-error-event[
>>            protocol-error-reason='checksum-error']/",
>>     }
>>  }
>> 
>>      Figure 16: Establishing a Subscription Error Reason via XPath
>> 
>> ...
>> 
>>  POST /restconf/operations
>>       /ietf-subscribed-notifications:modify-subscription
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-subtree-filter": {
>>          "/ietf-vrrp:vrrp-protocol-error-event" : {}
>>        }
>>     }
>>  }
>>               Figure 17: Example "modify-subscription" RPC
>> 
>> Corrected Text
>> --------------
>> NEW1:
>>  POST /restconf/operations
>>       /ietf-subscribed-notifications:establish-subscription
>> 
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-xpath-filter":
>>          "/ietf-vrrp:vrrp-protocol-error-event[
>>            protocol-error-reason='checksum-error']/"
>>     }
>>  }
>> 
>>      Figure 16: Establishing a Subscription Error Reason via XPath
>> 
>> ...
>> 
>>  POST /restconf/operations
>>       /ietf-subscribed-notifications:modify-subscription
>> 
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-subtree-filter": {
>>          "/ietf-vrrp:vrrp-protocol-error-event" : {}
>>        }
>>     }
>>  }
>>               Figure 17: Example "modify-subscription" RPC
>> 
>> or NEW2 (to follow the conventions in 1.1.6 of RFC8040)
>> 
>> 
>>  POST /restconf/operations\
>>       /ietf-subscribed-notifications:establish-subscription
>> 
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-xpath-filter":
>>          "/ietf-vrrp:vrrp-protocol-error-event[\
>>            protocol-error-reason='checksum-error']/"
>>     }
>>  }
>> 
>>      Figure 16: Establishing a Subscription Error Reason via XPath
>> ...
>> 
>>  POST /restconf/operations\
>>       /ietf-subscribed-notifications:modify-subscription
>> 
>>  {
>>     "ietf-subscribed-notifications:input": {
>>        "stream": "NETCONF",
>>        "stream-subtree-filter": {
>>          "/ietf-vrrp:vrrp-protocol-error-event" : {}
>>        }
>>     }
>>  }
>>               Figure 17: Example "modify-subscription" RPC
>> 
>> Notes
>> -----
>> * There is a missing CRLF in both figures as per RFC9112:
>> 
>> --
>> HTTP-message   = start-line CRLF
>>                  *( field-line CRLF )
>>                  CRLF
>>                  [ message-body ]
>> --
>> 
>> * The last item in the JSON of figure 16 includes a trailing "," while it shouldn't.
>> 
>> 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. 
>> 
>> --------------------------------------
>> RFC8650 (draft-ietf-netconf-restconf-notif-15)
>> --------------------------------------
>> Title               : Dynamic Subscription to YANG Events and Datastores over RESTCONF
>> Publication Date    : November 2019
>> Author(s)           : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman
>> Category            : PROPOSED STANDARD
>> Source              : Network Configuration
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf