Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
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/eid7647
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 Sep 18, 2023, at 4:23 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC6991,
> "Common YANG Data Types".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7647
>
> --
> Type: Editorial
> Reported by: David Martínez García
>
> Section: 3
>
> Original Text
> -
> [...]
>
> typedef object-identifier-128 {
> type object-identifier {
>
> [...]
>
> (and other typedefs that appear in the latest revisions of the module)
>
> Corrected Text
> --
> [...]
>
> typedef object-identifier-128 {
> type yang:object-identifier {
>
> [...]
>
> (and other typedefs that appear in the latest revisions of the module)
>
> Notes
> -
> In Section 3, the textual definition of the "ietf-yang-types" module
> presents, in my opinion, inconsistencies when defining typedefs that point to
> other typedefs in the same module: sometimes the value for the "type" key
> contains the prefix of the module and sometimes not. Please, see the example
> attached. This can also be applied to other typedefs defined in the latest
> revisions of the module, such as "date-no-zone" and "time-no-zone". I think
> this should be addressed to provide clarification and consistency, and thus
> can be extended to other modules and the YANG standard as well. Thanks for
> your time.
>
> 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.
>
> --
> RFC6991 (draft-ietf-netmod-rfc6021-bis-03)
> --
> Title : Common YANG Data Types
> Publication Date: July 2013
> Author(s) : J. Schoenwaelder, Ed.
> Category: PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8407 (7416)
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/eid7416
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 Apr 7, 2023, at 5:50 AM, RFC Errata System
> 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
>
> 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 : 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 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 : 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8519 (7312)
Greetings 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/eid7312 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 Jan 18, 2023, at 6:29 AM, RFC Errata System > 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/eid7312 > > -- > Type: Editorial > Reported by: Mohamed Boucadair > > Section: A.1 > > Original Text > - > The "example-newco-acl" module is an example of a company's > proprietary model that augments the "ietf-acl" module. It shows how > to use 'augment' with an XML Path Language (XPath) expression to add > additional match criteria, actions, and default actions for when no > ACE matches are found. All these are company proprietary extensions > or system feature extensions. "example-newco-acl" is just an > example, and it is expected that vendors will create their own > proprietary models. > > Corrected Text > -- > The "example-newco-acl" module is an example of a company's > proprietary model that augments the "ietf-access-control-list" module. It > shows how > to use 'augment' with an XML Path Language (XPath) expression to add > additional match criteria, actions, and default actions for when no > ACE matches are found. All these are company proprietary extensions > or system feature extensions. "example-newco-acl" is just an > example, and it is expected that vendors will create their own > proprietary models. > > Notes > - > There is no "ietf-acl" module in the document. > > 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 > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)
Greetings 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/eid7313
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 Jan 18, 2023, at 7:02 AM, RFC Errata System
> 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
>
> --
> Type: Editorial
> Reported by: Mohamed Boucadair
>
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8528 (6857)
Hi Martin,
Per your message, EID 6857 has been deleted.
Thank you!
RFC Editor/cs
> On Mar 9, 2022, at 11:20 PM, Martin Björklund wrote:
>
> Hi,
>
> Chris Smiley wrote:
>>
>> Greetings,
>>
>> EID 6857 is almost identical to EID 5797. They differ in the enabled field
>> (one says true, one says false). Please let me know which errata is correct.
>
>
> EID 5797 is the correct one.
>
> For some reason, EID 6857 has mistyped the *original* text (according
> to EID 6857, the original text has "enabled": false, but RFC 8528 has
> "enabled": true).
>
>
> /martin
>
>
>>
>> Thank you.
>>
>> RFC Editor/cs
>>
>>
>>> On Feb 21, 2022, at 11:31 PM, RFC Errata System
>>> wrote:
>>>
>>> The following errata report has been submitted for RFC8528,
>>> "YANG Schema Mount".
>>>
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6857
>>>
>>> --
>>> Type: Editorial
>>> Reported by: Kokkiknamtan
>>>
>>> Section: A.2
>>>
>>> Original Text
>>> -
>>> {
>>>"ietf-interfaces:interfaces": {
>>> "interface": [
>>>{
>>> "name": "eth0",
>>> "type": "iana-if-type:ethernetCsmacd",
>>> "enabled": false,
>>> "ietf-logical-network-element:bind-lne-name": "eth0"
>>>}
>>> ]
>>>},
>>>
>>>
>>> Corrected Text
>>> --
>>> {
>>>"ietf-interfaces:interfaces": {
>>> "interface": [
>>>{
>>> "name": "eth0",
>>> "type": "iana-if-type:ethernetCsmacd",
>>> "enabled": false,
>>> "ietf-logical-network-element:bind-lne-name": "lne-1"
>>>}
>>> ]
>>>},
>>>
>>>
>>> Notes
>>> -
>>> leafref is for an LNE name, not an interface name
>>>
>>> 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.
>>>
>>> --
>>> RFC8528 (draft-ietf-netmod-schema-mount-12)
>>> --
>>> Title : YANG Schema Mount
>>> Publication Date: March 2019
>>> Author(s) : M. Bjorklund, L. Lhotka
>>> Category: PROPOSED STANDARD
>>> Source : Network Modeling
>>> Area: Operations and Management
>>> Stream : IETF
>>> Verifying Party : IESG
>>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8528 (6857)
Greetings,
EID 6857 is almost identical to EID 5797. They differ in the enabled field
(one says true, one says false). Please let me know which errata is correct.
Thank you.
RFC Editor/cs
> On Feb 21, 2022, at 11:31 PM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC8528,
> "YANG Schema Mount".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6857
>
> --
> Type: Editorial
> Reported by: Kokkiknamtan
>
> Section: A.2
>
> Original Text
> -
> {
> "ietf-interfaces:interfaces": {
> "interface": [
> {
> "name": "eth0",
> "type": "iana-if-type:ethernetCsmacd",
> "enabled": false,
> "ietf-logical-network-element:bind-lne-name": "eth0"
> }
> ]
> },
>
>
> Corrected Text
> --
> {
> "ietf-interfaces:interfaces": {
> "interface": [
> {
> "name": "eth0",
> "type": "iana-if-type:ethernetCsmacd",
> "enabled": false,
> "ietf-logical-network-element:bind-lne-name": "lne-1"
> }
> ]
> },
>
>
> Notes
> -
> leafref is for an LNE name, not an interface name
>
> 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.
>
> --
> RFC8528 (draft-ietf-netmod-schema-mount-12)
> --
> Title : YANG Schema Mount
> Publication Date: March 2019
> Author(s) : M. Bjorklund, L. Lhotka
> Category: PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
