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
[netmod] [Editorial Errata Reported] RFC6991 (7647)
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] Poll on YANG Versioning NBC Approach
On 13/09/2023 16.36, Ladislav Lhotka wrote: Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a): If you are asking whether I'd like to see a new version of YANG for the sole purpose of changing those MUST and MUST NOTs - no, I would not. However, a change like this mandates a yang-version bump, IMHO. Right, so we have two ugly options, but bumping YANG version really makes no sense, so breaking those few tools that check update rules looks like a better choice to me. We have already seen cases that the update rules prevented fixing problems in YANG modules in a straightforward way, and backward-compatible fixes negatively affected module readability. This is inevitable until the ecosystem of YANG modules stabilizes. That's why I think changing update rules from MUST to SHOULD is appropriate - it should have been so from the beginning. +1. Regards, Robert OpenPGP_signature Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02
I support the adoption of this document as WG doc. Alex > On 12 Sep 2023, at 00:22, Lou Berger wrote: > > Hello, > > This email begins a 2-week adoption poll for: > https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/ > > Please voice your support or technical objections to adoption on the > list by the end of the day (any time zone) Sept 25. > > Thank you, > Lou (as Co-chair) > > ___ > 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
