Re: [netmod] Changing an identity base
On 30/01/2023 11:17, Martin Björklund wrote:
Hi,
Jernej Tuljak wrote:
On 30/01/2023 10:19, Italo Busi wrote:
Yes, the intention is not to change the semantic of bar but to
introduce a more “restricted” identity from which bar could be derived
Something like introducing an identity for italian-car in between car
and Ferrari identities
I understand your intention. I do not understand the intention behind
text in RFC 7950, however.
My clarification request was aimed at RFC 7950 authors and whether a
revision like this could be considered as not changing the semantics
of the original identity definition because:
Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other
than
those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier.
So, RFC authors: Is "NEWB:bar" definition semantically equivalent to
"OLD:bar" definition?
I think that this change isn't allowed according to RFC 7950, but it
should have been. If there ever is a new version of YANG, this should
be fixed.
The quoted text says:
if a non-editorial change is made to any definition other
than those specifically allowed above, then this MUST be achieved by a
new definition with a new identifier
This is a non-editorial change that is not "specifically allowed
above".
That has been my interpretation as well so far. Our tools were
implemented accordingly. I believe that the Pyang plugin also reports an
error for a change like this.
Jernej
/martin
Jernej
Italo
*From:* Jernej Tuljak
*Sent:* lunedì 30 gennaio 2023 08:51
*To:* Italo Busi ; netmod@ietf.org
*Subject:* Re: [netmod] Changing an identity base
On 27/01/2023 17:54, Italo Busi wrote:
According to section 11 of RFC7950, the following change is
considered BC:
o A "base" statement may be added to an "identity" statement.
Since, as explained in section 7.18.2 of RFC7950, the derivation
of identities is transitive, my understanding is that replacing a
"base" statement with new "base" statement which is derived from
the previous one is also a BC change.
Considering the example below, the NEW (A) change is BC according
to section 11 of RFC7950. However, NEW (B) is equivalent to NEW
(A), since the new baz is derived from foo, and therefore it is
also a BC change.
Is my understanding correct?
I'd like a clarification regarding this as well. Is "NEWB:bar"
definition semantically equivalent to "OLD:bar" definition?
Jernej
Thanks, Italo
OLD
identity foo {}
identity bar {
base foo;
}
NEW (A)
identity foo {}
identity baz {
base foo
}
identity bar {
base foo;
base baz;
}
NEW (B)
identity foo {}
identity baz {
base foo
}
identity bar {
base baz;
}
___
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] IPR Poll on draft-ietf-netmod-yang-semver-09
Thank you all! Everyone replied: "No, I'm not aware of any IPR that applies to this draft". We'll move to WGLC as soon as the IPR call on "yang-module-versioning" completes. Kent > On Jan 16, 2023, at 5:59 PM, Kent Watsen wrote: > > [NOTE: A response is needed from all listed in this message's "To" line, the > authors and contributors listed in the draft] > > > Authors, Contributors, WG, > > In preparation for a WGLC Call: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. If you are listed as a document author or contributor > please answer the above by responding to this email regardless > of whether or not you are aware of any relevant IPR. This > document will not advance to the next stage until a response > has been received from each author. > > If you are on the WG email list or attend WG meetings but are not > listed as an author or contributor, we remind you of your obligations > under the IETF IPR rules which encourages you to notify the IETF > if you are aware of IPR of others on an IETF contribution, or to > refrain from participating in any contribution or discussion related > to your undisclosed IPR. For more information, please see the RFCs > listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > Kent and Lou > > PS Please include all listed in the headers of this message in your > response. > ___ > 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] RFC8519 (7313)
Rob,
Errata should be accepted.
Kent
> On Jan 18, 2023, at 10: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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8519 (7312)
Rob, Errata should be accepted. Kent > On Jan 18, 2023, at 9: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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Modeling unknown bits in YANG (draft-haas-netmod-unknown-bits-00)
Jürgen, On Fri, Jan 27, 2023 at 09:18:32PM +0100, Jürgen Schönwälder wrote: > Depending on context, I think it is 'modeling' when it is about > choosing the type or 'rendering' / 'representing' when it is about how > a type's value is rendered (in XML). Some proposals: I've incorporated all of these suggestions and published as -01. Thanks. > > What I would have preferred to exist in the YANG language is a bits type > > that provides for automatic default naming for unassigned positions. Thus, > > using your example: > > restart b1 > > > > I understand the motivations to not do this since there's a desire to have > > stable naming for the position 1 element. Thus, we're driven to this > > discussion. > > I assume there are use cases where this would be useful and perhaps > others where it is less so. But more likely nobody thought about this > 13 years ago. I do not know whether we have a YANG next issue for this > but this may be an issue worth to look at if there is ever another > version of YANG. Agreed. It might be useful for the YANG doctors to comment on how things have been modeled for unknown bit state elsewhere as they've done their work. I find it likely that other modules have chosen to not be this thorough. It's my hope that this pattern is a useful one and becomes recommended. -- Jeff ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Changing an identity base
Hi,
Jernej Tuljak wrote:
> On 30/01/2023 10:19, Italo Busi wrote:
> >
> > Yes, the intention is not to change the semantic of bar but to
> > introduce a more “restricted” identity from which bar could be derived
> >
> > Something like introducing an identity for italian-car in between car
> > and Ferrari identities
> >
>
> I understand your intention. I do not understand the intention behind
> text in RFC 7950, however.
>
> My clarification request was aimed at RFC 7950 authors and whether a
> revision like this could be considered as not changing the semantics
> of the original identity definition because:
>
> Otherwise, if the semantics of any previous definition are changed
> (i.e., if a non-editorial change is made to any definition other
> than
> those specifically allowed above), then this MUST be achieved by a
> new definition with a new identifier.
>
> So, RFC authors: Is "NEWB:bar" definition semantically equivalent to
> "OLD:bar" definition?
I think that this change isn't allowed according to RFC 7950, but it
should have been. If there ever is a new version of YANG, this should
be fixed.
The quoted text says:
if a non-editorial change is made to any definition other
than those specifically allowed above, then this MUST be achieved by a
new definition with a new identifier
This is a non-editorial change that is not "specifically allowed
above".
/martin
>
> Jernej
>
> > Italo
> >
> > *From:* Jernej Tuljak
> > *Sent:* lunedì 30 gennaio 2023 08:51
> > *To:* Italo Busi ; netmod@ietf.org
> > *Subject:* Re: [netmod] Changing an identity base
> >
> > On 27/01/2023 17:54, Italo Busi wrote:
> >
> > According to section 11 of RFC7950, the following change is
> > considered BC:
> >
> > o A "base" statement may be added to an "identity" statement.
> >
> > Since, as explained in section 7.18.2 of RFC7950, the derivation
> > of identities is transitive, my understanding is that replacing a
> > "base" statement with new "base" statement which is derived from
> > the previous one is also a BC change.
> >
> > Considering the example below, the NEW (A) change is BC according
> > to section 11 of RFC7950. However, NEW (B) is equivalent to NEW
> > (A), since the new baz is derived from foo, and therefore it is
> > also a BC change.
> >
> > Is my understanding correct?
> >
> >
> > I'd like a clarification regarding this as well. Is "NEWB:bar"
> > definition semantically equivalent to "OLD:bar" definition?
> >
> > Jernej
> >
> >
> > Thanks, Italo
> >
> > OLD
> >
> > identity foo {}
> >
> > identity bar {
> >
> > base foo;
> >
> > }
> >
> > NEW (A)
> >
> > identity foo {}
> >
> > identity baz {
> >
> > base foo
> >
> > }
> >
> > identity bar {
> >
> > base foo;
> >
> > base baz;
> >
> > }
> >
> > NEW (B)
> >
> > identity foo {}
> >
> > identity baz {
> >
> > base foo
> >
> > }
> >
> > identity bar {
> >
> > base baz;
> >
> > }
> >
> >
> >
> > ___
> >
> > 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] Changing an identity base
On 30/01/2023 10:19, Italo Busi wrote:
Yes, the intention is not to change the semantic of bar but to
introduce a more “restricted” identity from which bar could be derived
Something like introducing an identity for italian-car in between car
and Ferrari identities
I understand your intention. I do not understand the intention behind
text in RFC 7950, however.
My clarification request was aimed at RFC 7950 authors and whether a
revision like this could be considered as not changing the semantics of
the original identity definition because:
Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier.
So, RFC authors: Is "NEWB:bar" definition semantically equivalent to
"OLD:bar" definition?
Jernej
Italo
*From:* Jernej Tuljak
*Sent:* lunedì 30 gennaio 2023 08:51
*To:* Italo Busi ; netmod@ietf.org
*Subject:* Re: [netmod] Changing an identity base
On 27/01/2023 17:54, Italo Busi wrote:
According to section 11 of RFC7950, the following change is
considered BC:
o A "base" statement may be added to an "identity" statement.
Since, as explained in section 7.18.2 of RFC7950, the derivation
of identities is transitive, my understanding is that replacing a
"base" statement with new "base" statement which is derived from
the previous one is also a BC change.
Considering the example below, the NEW (A) change is BC according
to section 11 of RFC7950. However, NEW (B) is equivalent to NEW
(A), since the new baz is derived from foo, and therefore it is
also a BC change.
Is my understanding correct?
I'd like a clarification regarding this as well. Is "NEWB:bar"
definition semantically equivalent to "OLD:bar" definition?
Jernej
Thanks, Italo
OLD
identity foo {}
identity bar {
base foo;
}
NEW (A)
identity foo {}
identity baz {
base foo
}
identity bar {
base foo;
base baz;
}
NEW (B)
identity foo {}
identity baz {
base foo
}
identity bar {
base baz;
}
___
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] Changing an identity base
Yes, the intention is not to change the semantic of bar but to introduce a more
“restricted” identity from which bar could be derived
Something like introducing an identity for italian-car in between car and
Ferrari identities
Italo
From: Jernej Tuljak
Sent: lunedì 30 gennaio 2023 08:51
To: Italo Busi ; netmod@ietf.org
Subject: Re: [netmod] Changing an identity base
On 27/01/2023 17:54, Italo Busi wrote:
According to section 11 of RFC7950, the following change is considered BC:
o A "base" statement may be added to an "identity" statement.
Since, as explained in section 7.18.2 of RFC7950, the derivation of identities
is transitive, my understanding is that replacing a "base" statement with new
"base" statement which is derived from the previous one is also a BC change.
Considering the example below, the NEW (A) change is BC according to section 11
of RFC7950. However, NEW (B) is equivalent to NEW (A), since the new baz is
derived from foo, and therefore it is also a BC change.
Is my understanding correct?
I'd like a clarification regarding this as well. Is "NEWB:bar" definition
semantically equivalent to "OLD:bar" definition?
Jernej
Thanks, Italo
OLD
identity foo {}
identity bar {
base foo;
}
NEW (A)
identity foo {}
identity baz {
base foo
}
identity bar {
base foo;
base baz;
}
NEW (B)
identity foo {}
identity baz {
base foo
}
identity bar {
base baz;
}
___
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
