On Mon, Apr 10, 2023 at 10:19 PM <mohamed.boucad...@orange.com> wrote:
> Hi Andy,
>
>
>
> Which convention are you referring to?
>
>
>
I mixed up the "prefix table" with "RFC NNNN".
Your fix is not correct.
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.
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.
What is cited here are excerpt from RFC8407.
>
>
>
> Cheers,
>
> Med
>
Andy
>
>
> *De :* Andy Bierman <a...@yumaworks.com>
> *Envoyé :* vendredi 7 avril 2023 17:36
> *À :* RFC Errata System <rfc-edi...@rfc-editor.org>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>;
> netmod@ietf.org
> *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 <
> rfc-edi...@rfc-editor.org> 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 <mohamed.boucad...@orange.com>
>
> 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.
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
