Re: [netmod] [Editorial Errata Reported] RFC8407 (7416)

[[e-mail]]

Hi Andy,

Please see inline.

Cheers,
Med

De : Andy Bierman <[e-mail]>
Envoyé : mardi 11 avril 2023 16:58
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : RFC Errata System <[e-mail]>; [e-mail]
Objet : Re: [Editorial Errata Reported] RFC8407 (7416)



On Mon, Apr 10, 2023 at 10:19 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

Which convention are you referring to?


I mixed up the "prefix table" with "RFC NNNN".

Your fix is not correct.
[Med] It is correct as the example was extracted from draft-ietf-netconf-rfc6536bis. The fix is contextualized.

The correct convention is more like:

        reference
          // RFC Editor: Remove this line and replace NNNN with the correct RFC number
          "RFC NNNN: ...";

I do not really think an RFC update for this sort of bugfix is needed.
[Med] Not sure how this relates to this erratum.

I am not against a WG effort to create 8704bis, but there are already
many RFCs that update it. An update focusing on idnits would not be very interesting.
[Med] That’s not what the proposed 8407 is about, but let’s discuss that separately. Thanks.



What is cited here are excerpt from RFC8407.

Cheers,
Med


Andy


De : Andy Bierman <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 7 avril 2023 17:36
À : RFC Errata System <[e-mail]<mailto:[e-mail]>>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: [Editorial Errata Reported] RFC8407 (7416)

Hi,

This errata cites a documentation convention that was created after RFC 8407 was published.

It is unfortunate that this RFC is an ad-hoc mix of YANG Usage Guidelines
and IETF Documentation Guidelines.  The latter is much less stable.

Andy


On Fri, Apr 7, 2023 at 5:50 AM RFC Errata System <[e-mail]<mailto:[e-mail]>> wrote:
The following errata report has been submitted for RFC8407,
"Guidelines for Authors and Reviewers of Documents Containing YANG Data Models".

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

--------------------------------------
Type: Editorial
Reported by: Mohamed Boucadair <[e-mail]<mailto:[e-mail]>>

Section: 4.8

Original Text
-------------
      revision "2017-12-11" {
        description
          "Added support for YANG 1.1 actions and notifications tied to
           data nodes.  Clarify how NACM extensions can be used by other
           data models.";
        reference
          "RFC 8407: Network Configuration Protocol (NETCONF)
                     Access Control Model";
      }

Corrected Text
--------------
      revision "2017-12-11" {
        description
          "Added support for YANG 1.1 actions and notifications tied to
           data nodes.  Clarify how NACM extensions can be used by other
           data models.";
        reference
          "RFC UUUU: Network Configuration Access Control Model";
      }

Notes
-----
This example is supposed to illustrate the use of revisions in unpublished updates. Having an RFC under  the reference clause is inconsistent:

   o  published: A stable release of a module or submodule.  For
      example, the "Request for Comments" described in Section 2.1 of
      [RFC2026] is considered a stable publication.

   o  unpublished: An unstable release of a module or submodule.  For
      example the "Internet-Draft" described in Section 2.2 of [RFC2026]
      is considered an unstable publication that is a work in progress,
      subject to change at any time.

I suspect that RFC XXXX in draft-ietf-netmod-rfc6087bis was erroneously replaced by RFC 8407:

      revision "2017-12-11" {
        description
          "Added support for YANG 1.1 actions and notifications tied to
           data nodes. Clarify how NACM extensions can be used by other
           data models.";
        reference
          "RFC XXXX: Network Configuration Protocol (NETCONF)
                     Access Control Model";
      }

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.

--------------------------------------
RFC8407 (draft-ietf-netmod-rfc6087bis-20)
--------------------------------------
Title               : Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
Publication Date    : October 2018
Author(s)           : A. Bierman
Category            : BEST CURRENT PRACTICE
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.