Hello Rob, I agree: so introducing the “not” operator into if-feature IMHO was a mistake. It can have its uses, but it is very dangerous.
regards Balazs (Sending it to the full netmod group.) From: Rob Wilton (rwilton) <rwil...@cisco.com> Sent: 2019. október 11., péntek 12:50 To: Balázs Lengyel <balazs.leng...@ericsson.com>; Reshad Rahman (rrahman) <rrah...@cisco.com>; netmod-ver...@ietf.org Subject: RE: [Netmod-ver-dt] Adding a feature is it BC or NBC ? [was: RE: YANG packages draft - now ready for review please] Hi Balazs, This is an interesting example. It doesn’t just break packages, but breaks YANG conformance more generally, particularly if the leaf was also marked as mandatory. I.e. whether a server implements the radius feature will determine whether or not the configuration is valid. Basically, I think that this is an unwise use of if-feature. Generally, I think that the principle behind features is that they represent functionality that is optional to support, and probably should not be used in this way to remove nodes from the underlying model. I think that this is probably a bug/flaw in YANG. Thanks, Rob From: Netmod-ver-dt <netmod-ver-dt-boun...@ietf.org <mailto:netmod-ver-dt-boun...@ietf.org> > On Behalf Of Balázs Lengyel Sent: 10 October 2019 23:57 To: Rob Wilton (rwilton) <rwil...@cisco.com <mailto:rwil...@cisco.com> >; Reshad Rahman (rrahman) <rrah...@cisco.com <mailto:rrah...@cisco.com> >; netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> Subject: [Netmod-ver-dt] Adding a feature is it BC or NBC ? [was: RE: YANG packages draft - now ready for review please] Hello, Adding a new feature MAY or MAY NOT be backward compatible. Think about the following YANG: feature radius {} leaf xxxx { if-feature “not radius”; } So if I add radius it actually removes the leaf xxx. NBC. regards Balazs Regards Balazs From: Netmod-ver-dt <netmod-ver-dt-boun...@ietf.org <mailto:netmod-ver-dt-boun...@ietf.org> > On Behalf Of Rob Wilton (rwilton) Sent: 2019. október 10., csütörtök 13:17 To: Reshad Rahman (rrahman) <rrah...@cisco.com <mailto:rrah...@cisco.com> >; netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> Subject: Re: [Netmod-ver-dt] YANG packages draft - now ready for review please Hi Reshad, Thanks for the comments. I’ve fixed all of the typos. For the Abstract: Old: This document defines YANG packages, a versioned organizational structure holding a set of related YANG modules, that can be used to simplify the conformance and sharing of YANG schema. It describes how YANG instance data documents are used to define YANG packages, and how the YANG library information published by a server can be augmented with packaging related information. Proposed: This document defines YANG packages, a versioned organizational structure holding a set of related YANG modules, that collectively define a YANG schema. It describes how YANG instance data documents are used to define YANG packages, and how the YANG library information published by a server can be augmented with packaging related information. For 5.2.1.1 Re: “Should this list also include/state “any NBC changes to a module in the package”?” Ah, I see. This is what the following current text of the second paragraph was meant to mean Old: <t>Changing a package import to select a package version that is non-backwards-compatible to the prior package version, or removing a previously imported package.</t> <t>Changing a module import to select a module revision that is non-backwards-compatible to the prior module revision, or removing a previously implemented module.</t> <t>Removing a previously supported feature.</t> <t>Adding, changing, or removing a deviation that is considered a non-backwards-compatible change to the affected data node in the schema associated with the prior package version.</t> Perhaps the following text would be more clear: <t>Changing an 'imported-packages' list entry to select a package version that is non-backwards-compatible to the prior package version, or removing a previously imported package.</t> <t>Changing a 'modules' or 'import-only-modules' list entry to select a module revision that is non-backwards-compatible to the prior module revision, or removing a previously implemented module.</t> <t>Removing a feature from the 'supported-feature' leaf-list.</t> <t>Adding, changing, or removing a deviation that is considered a non-backwards-compatible change to the affected data node in the schema associated with the prior package version.</t> Re 5.5.1 “MUST” instead of “SHOULD” for uniqueness. Probably we should discuss today, but my default position is that I think that I will change this. I think that my question was that how do you enforce global uniqueness …. Thanks, Rob From: Reshad Rahman (rrahman) <rrah...@cisco.com <mailto:rrah...@cisco.com> > Sent: 10 October 2019 03:57 To: Rob Wilton (rwilton) <rwil...@cisco.com <mailto:rwil...@cisco.com> >; netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> Subject: Re: [Netmod-ver-dt] YANG packages draft - now ready for review please Hi Rob, Looks good, but TBH I haven’t gone over the minute details of the examples etc. Some comments. Abstract The sentence with “simplify the conformance and sharing of YANG schema” doesn’t jive well to me. I think I know what you mean (we probably discussed this previously), I don’t have better phrasing to propose. Only suggestion I have is to consider shortening the abstract. Terminology s/oraganization/organization/ Introduction s/appendicies/appendices/? Objectives s/were a client/where a client/ YANG Package definition s/oraganization/organization/ s/collectively define/collectively defines/? 3rd paragraph starting with “Each version of a YANG package defines…”. Do this in bullet form instead? 5.1 Package definition rules s/decendent/descendent/ s/supercedes/supersedes/ 5.2.1 Leaf is ‘nbc-changes’ (not ‘nbc-change’) 5.2.1.1. Non-Backwards-compatible changes Should this list also include/state “any NBC changes to a module in the package”? 5.3 s/libary/library/ 5.5.1 Why SHOULD is used for uniqueness? Why not MUST? s/publically/publicly/? 6 s/pacakge/package/ Regards, Reshad. From: Netmod-ver-dt <netmod-ver-dt-boun...@ietf..org <mailto:netmod-ver-dt-boun...@ietf.org> > on behalf of "Rob Wilton (rwilton)" <rwil...@cisco.com <mailto:rwil...@cisco.com> > Date: Monday, October 7, 2019 at 9:58 AM To: "netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> " <netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> > Subject: [Netmod-ver-dt] YANG packages draft - now ready for review please Hi, I think that this document has had sufficient updates that it is ready for review. The latest version is available at per the commit information above, or attached. I appreciate that it is quite short notice, but if it is possible for folks to review and provide comments before Thursday’s meeting that probably be helpful. Thanks, Rob
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
