In that case, yes, this errata should be accepted.
> On Jan 18, 2023, at 11:03 AM, <mohamed.boucad...@orange.com>
> <mohamed.boucad...@orange.com> wrote:
>
> Hi Mahesh,
>
> I also recall some of that discussion… but that is not related to this
> erratum given the following prefix used in the import:
>
> CURRENT:
> import ietf-access-control-list {
> prefix acl;
> }
>
> Cheers,
> Med
>
> De : Mahesh Jethanandani <mjethanand...@gmail.com>
> Envoyé : mercredi 18 janvier 2023 19:32
> À : netmod <netmod@ietf.org>
> Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Sonal
> Agarwal <sagarwa...@gmail.com>; huangyi...@yahoo.com; d...@blairhome.com
> Objet : Re: [Editorial Errata Reported] RFC8519 (7313)
>
> There was a lot of discussion on the usage of what prefix should be used when
> importing a module, possibly after this draft was published. However, it is a
> BCP, and most tools will not complain if a prefix other than what is defined
> in the module is used. I am not sure if a BCP rises to the level of an errata.
>
> Thanks.
>
>
> On Jan 18, 2023, at 7:02 AM, RFC Errata System <rfc-edi...@rfc-editor.org
> <mailto:rfc-edi...@rfc-editor.org>> wrote:
>
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7313
> <https://www.rfc-editor.org/errata/eid7313>
>
> --------------------------------------
> Type: Editorial
> Reported by: Mohamed Boucadair <mohamed.boucad...@orange.com
> <mailto:mohamed.boucad...@orange.com>>
>
> Section: A.1
>
> Original Text
> -------------
> The following figure is the tree diagram of example-newco-acl. In
> this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
> ietf-acl:matches are augmented with two new choices: protocol-
> payload-choice and metadata. The protocol-payload-choice uses a
> grouping with an enumeration of all supported protocol values.
> Metadata matches apply to fields associated with the packet, that are
> not in the packet header, such as overall packet length. In another
> example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
> ietf-acl:actions are augmented with a new choice of actions.
>
> Corrected Text
> --------------
> The following figure is the tree diagram of example-newco-acl. In
> this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
> are augmented with two new choices: protocol-payload-choice and
> metadata. The protocol-payload-choice uses a
> grouping with an enumeration of all supported protocol values.
> Metadata matches apply to fields associated with the packet, that are
> not in the packet header, such as overall packet length. In another
> example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions
> are augmented with a new choice of actions.
>
> Notes
> -----
> The prefix is "acl" not "ietf-acl"
>
> ==
> module ietf-access-control-list {
> yang-version 1.1;
> namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
> prefix acl;
> ...
> ==
>
> 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.
>
> --------------------------------------
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --------------------------------------
> Title : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date : March 2019
> Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category : PROPOSED STANDARD
> Source : Network Modeling
> Area : Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
>
> Mahesh Jethanandani
> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
