Re: [netmod] Does defining a feature require the module be implemented?
On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote: > Kent Watsen wrote: > > > > > Hmm, I don't remember why this was changed in RFC 8525. Perhaps this > was by accident? The only text I can find is this in RFC 7950: > > Not by accident. I did not want the new list. The main rationale was that the 2 lists needed different keys. The import-only-module list has [name, revision] instead of just [name]. 5.6.5. Implementing a Module > > A server implements a module if it implements the module's data > nodes, RPCs, actions, notifications, and deviations. > > Which seems to indicate that "implementing a module" is NOT required > for a feature to be supported. > Agreed. - 7.20.1, para 1: not specific to modules, refers to the model - 7.20.1, para 6: "server MUST support all dependent features". No mention of modules, just features. > > 2) If it is the case that the module must be implemented to use its > > features, then I need to update some of my modules (e.g., crypto-types > > and friends) to explicitly disable the protocol-accessible tree when > > the module is implemented *only* to use its features. > > Since RFC 8525 doesn't allow a feature to be supported w/o also > implementing the module, I think this is the solution for now. And it > is not wrong even if RFC 8525 was updated to support features from > imported modules. > Deviation-stmts would be required to "undo" the base module implementation requirement. Looks like RFC 7895 got this part right. The 'feature' leaf-list may apply to imported modules. The same feature can only appear once, no matter how many revisions of a module are imported. Andy > > > 3) I wish more modules would following the pattern of having the > > global protocol accessible tree be defined via a "uses" of a grouping > > defined in the module. In another recent project, I had to hack the > > topology modules defined in RFC 8345 (to convert the containers to > > groupings) to enable a multiplicity of "abstract network topologies" > > to be configured. The assumption that only a single global instance > > is ever needed is proving to be invalid in my work time and again. > > This is a classic problem w/ any model... And you can extend it to > other things as well, not only top-level nodes; whenever you define a > leaf, perhaps someone could support multiple instances and wished it > was a leaf-list instead? And in a leaf-list, perhaps someone wanted > to add additional properites to each item, and wished it was a list > instead? And so on... > > > /martin > > ___ > 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] IANA managed modules for TE object types
+ netmod WG, and YANG Drs. Widening scope to gather more opinions. So far, we have some opinions that are proto adding such IANA managed modules. However, thers have raised concerns at transferring full ownership/control to IANA -- especially when mapping from IANA Identifiers to string based YANG identityref is required. We are also aware of a proposal in netmod in draft-boucadair-netmod-iana-registries – we are wondering if we have further input that will help YANG document authors moving forward. Regards, Tarek From: Tarek Saad Date: Friday, May 13, 2022 at 1:59 PM To: t...@ietf.org Cc: Adrian Farrel Subject: IANA managed modules for TE object types Hi WG, During the review of draft-ietf-teas-yang-te, Adrian raised an important point about IANA managing some YANG module that models specific TE types. For example, ID draft-ietf-teas-yang-te was modelling ‘no-path’ some error reasons as listed in https://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector-tlv or association types as defined in https://www.iana.org/assignments/pcep/pcep.xhtml#association-type-field. There are obvious advantages to having such YANG types in separate modules and letting IANA manage them. For example, 1. Other TE modules can freely import such types modules (without needing to import feature modules such as one defined in draft-ietf-teas-yang-te). 2. Allowing IANA to manage these modules may facilitate extensions in the future (IANA can automatically ensure that IANA types and YANG module are in sync). The authors discussed this suggestion and would like to proceed with it, but want to make sure this is the recommended approach for other types that are managed by IANA and may be modelled in YANG in the future. Regards, Tarek (for the co-authors of draft-ietf-teas-yang-te) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] YANG Versioning Weekly Call Minutes - 2022-05-17
YANG Versioning Weekly Call Minutes - 2022-05-17 We further discussed the use of per-element NBC/BC marking: - mixing a lot of detailed per-element history in a module may not be as clean as keeping it as "the current API" - in some more extreme cases, could end up with a module that is more history than API - doesn't handle an element that is removed from a module - less likely to get it correct from authors - if a tool can do it anyway, then why mark it all up right in the module ? - versioning in other areas is often "aggregated" at some level - TBD if it would have some complications/issues when considering branching and porting elements from one branch to another Proposal a: - NBC & BC per-element tags, mandatory when the diff tool is going to guess wrong (e.g. a description change is actually an NBC change instead of the default assumption of being editorial) - may be added to any element at author's discretion (i.e. can mark things the diff tool will also identify) Proposal b: - NBC marker only - always mandatory Proposal c: - Proposal A, but IETF MUST always mark NBC against elements We also briefly discussed other metadata (e.g. "introduced in" tag) but we were leaning away from these towards the end of the meeting. Jason -- Versioning work on Github: https://github.com/netmod-wg/yang-ver-dt -- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Does defining a feature require the module be implemented?
On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote:
> Kent Watsen wrote:
> >
> >
> > > On May 18, 2022, at 2:05 AM, Martin Björklund
> > > wrote:
> > >
> > >> PS: the answer to this impacts the "crypto-types and friends" drafts
> > >> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> > >> a recent change in `yanglint`) that the implementation-status of a
> > >> module is orthogonal to what features supported.
> > >
> > > Can you show a specific example where this is a problem?
> >
> >
> > Background:
> >
> > The genesis of this issue arises from a change (I think!) in
> > instance-document validation behavior from yanglint 1.x and 2.x, which
> > I've been switching to, whereby validation is now failing due to an
> > assumption that a module is *implemented* when the module is targeted
> > by the "--features" parameter, even if only to explicitly indicate the
> > *no* features are defined (i.e., "--featues=foo:", note that there are
> > no feature-names listed after the colon). As an aside, this seems a
> > bit like "the tail wagging the dog", but the reasoning was/is that
> > features can only be defined if a module is implemented and therefore
> > it makes sense to auto-implement a module even though it wasn't
> > explicitly listed as such on the command line.
> >
> > Issue:
> >
> > An issue arises when a module (like ietf-keystore) defines a grouping
> > (like "keystore-grouping") that is used both to allow instances in
> > other data models as well as a "global" instance when the module is
> > implemented. i.e., container keystore { uses keystore-grouping; }
> >
> > In ietf-keystore, a feature (central-keystore-supported) is used to
> > enable leafrefs to the global instance for cases when the module is
> > implemented (e.g., see local-or-keystore-symmetric-key-grouping).
> > However, because it was not anticipated that a module had to be
> > implemented in order for a feature to be defined (as was allowed by
> > RFC 7895 YANG Library), the "central-keystore-supported" feature
> > statement was NOT placed on the root node of the protocol-accessible
> > tree.
> >
> > So, in the case of NOT wanting the global keystore instance and yet
> > there IS a desire to define another keystore feature (e.g.,
> > asymmetric-keys), it seems that 1) the module MUST be implemented
> > *and* the root node of the protocol-accessible tree MUST have an
> > "if-feature central-keystore-supported" statement.
> >
> > Closing thoughts:
> >
> > 1) I'm not saying it is wrong that a module must be implemented in
> > order to define features defined in it. But I am noting that I can't
> > find where this behavior is defined (e.g., in RFC 7950). Also I note
> > that RFC 7895 enabled features to be defined independent of
> > implementation-status while RFC 8525 doesn't. As a co-author of RFC
> > 8525, I don't recall this being discussed and wonder what
> > justification was used, as folks are pointing to and working backwards
> > from RFC 8525 to indicate that it must be so.
>
> Hmm, I don't remember why this was changed in RFC 8525. Perhaps this
> was by accident? The only text I can find is this in RFC 7950:
>
> 5.6.5. Implementing a Module
>
> A server implements a module if it implements the module's data
> nodes, RPCs, actions, notifications, and deviations.
>
>
But RFC 7950 also says:
Any set of data definition nodes may be replaced with another
set
of syntactically and semantically equivalent nodes. For example,
a set of leafs may be replaced by a "uses" statement of a grouping
with the same leafs.
If a module is re-factored such that previously inline definitions are now
imported,
then the data model does not change. Therefore the conformance for the
model does not change.
Yet another demonstration that YANG conformance really only applies to a
conceptual data model,
(use-cases) and not independently to each module in the data model.
Andy
Which seems to indicate that "implementing a module" is NOT required
> for a feature to be supported.
>
> > 2) If it is the case that the module must be implemented to use its
> > features, then I need to update some of my modules (e.g., crypto-types
> > and friends) to explicitly disable the protocol-accessible tree when
> > the module is implemented *only* to use its features.
>
> Since RFC 8525 doesn't allow a feature to be supported w/o also
> implementing the module, I think this is the solution for now. And it
> is not wrong even if RFC 8525 was updated to support features from
> imported modules.
>
>
> > 3) I wish more modules would following the pattern of having the
> > global protocol accessible tree be defined via a "uses" of a grouping
> > defined in the module. In another recent project, I had to hack the
> > topology modules defined in RFC 8345 (to convert the containers to
> > groupings) to enable a multiplicity of "abstract network topologies"
> > to be configured. The assumption
Re: [netmod] Does defining a feature require the module be implemented?
Kent Watsen wrote:
>
>
> > On May 18, 2022, at 2:05 AM, Martin Björklund
> > wrote:
> >
> >> PS: the answer to this impacts the "crypto-types and friends" drafts
> >> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> >> a recent change in `yanglint`) that the implementation-status of a
> >> module is orthogonal to what features supported.
> >
> > Can you show a specific example where this is a problem?
>
>
> Background:
>
> The genesis of this issue arises from a change (I think!) in
> instance-document validation behavior from yanglint 1.x and 2.x, which
> I've been switching to, whereby validation is now failing due to an
> assumption that a module is *implemented* when the module is targeted
> by the "--features" parameter, even if only to explicitly indicate the
> *no* features are defined (i.e., "--featues=foo:", note that there are
> no feature-names listed after the colon). As an aside, this seems a
> bit like "the tail wagging the dog", but the reasoning was/is that
> features can only be defined if a module is implemented and therefore
> it makes sense to auto-implement a module even though it wasn't
> explicitly listed as such on the command line.
>
> Issue:
>
> An issue arises when a module (like ietf-keystore) defines a grouping
> (like "keystore-grouping") that is used both to allow instances in
> other data models as well as a "global" instance when the module is
> implemented. i.e., container keystore { uses keystore-grouping; }
>
> In ietf-keystore, a feature (central-keystore-supported) is used to
> enable leafrefs to the global instance for cases when the module is
> implemented (e.g., see local-or-keystore-symmetric-key-grouping).
> However, because it was not anticipated that a module had to be
> implemented in order for a feature to be defined (as was allowed by
> RFC 7895 YANG Library), the "central-keystore-supported" feature
> statement was NOT placed on the root node of the protocol-accessible
> tree.
>
> So, in the case of NOT wanting the global keystore instance and yet
> there IS a desire to define another keystore feature (e.g.,
> asymmetric-keys), it seems that 1) the module MUST be implemented
> *and* the root node of the protocol-accessible tree MUST have an
> "if-feature central-keystore-supported" statement.
>
> Closing thoughts:
>
> 1) I'm not saying it is wrong that a module must be implemented in
> order to define features defined in it. But I am noting that I can't
> find where this behavior is defined (e.g., in RFC 7950). Also I note
> that RFC 7895 enabled features to be defined independent of
> implementation-status while RFC 8525 doesn't. As a co-author of RFC
> 8525, I don't recall this being discussed and wonder what
> justification was used, as folks are pointing to and working backwards
> from RFC 8525 to indicate that it must be so.
Hmm, I don't remember why this was changed in RFC 8525. Perhaps this
was by accident? The only text I can find is this in RFC 7950:
5.6.5. Implementing a Module
A server implements a module if it implements the module's data
nodes, RPCs, actions, notifications, and deviations.
Which seems to indicate that "implementing a module" is NOT required
for a feature to be supported.
> 2) If it is the case that the module must be implemented to use its
> features, then I need to update some of my modules (e.g., crypto-types
> and friends) to explicitly disable the protocol-accessible tree when
> the module is implemented *only* to use its features.
Since RFC 8525 doesn't allow a feature to be supported w/o also
implementing the module, I think this is the solution for now. And it
is not wrong even if RFC 8525 was updated to support features from
imported modules.
> 3) I wish more modules would following the pattern of having the
> global protocol accessible tree be defined via a "uses" of a grouping
> defined in the module. In another recent project, I had to hack the
> topology modules defined in RFC 8345 (to convert the containers to
> groupings) to enable a multiplicity of "abstract network topologies"
> to be configured. The assumption that only a single global instance
> is ever needed is proving to be invalid in my work time and again.
This is a classic problem w/ any model... And you can extend it to
other things as well, not only top-level nodes; whenever you define a
leaf, perhaps someone could support multiple instances and wished it
was a leaf-list instead? And in a leaf-list, perhaps someone wanted
to add additional properites to each item, and wished it was a list
instead? And so on...
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Does defining a feature require the module be implemented?
On Wed, May 18, 2022 at 10:52 PM Jan Lindblad wrote: > Andy wrote: > > A server can support a module without any protocol-accessible objects in 3 > ways >- implement the module with no features supported >- implement the module with features supported >- import the module without implementing it > > To Martin's point, it is not clear that a client is harmed because a > server lists a module in > the 'module' list instead of the 'import-only-module' list. > > > Andy > > > I just want to attest to the real world harm it causes when a server lists > a module M in the modules list when it doesn't actually support it. > > The client then has to believe it is reasonable to issue a get-config > request for the contents of module M. But when it does, the server then > responds with an error, and the automation breaks down. The problem is > cured by the server listing the non-implemented module M as an > import-only-module. > > GET operations silently skip filters that do not match. There is no error returned. Modules are not required to contain config data nodes, so issuing a get-config request for every module does not seem like a good idea. A client should be able to determine that M does not have any configuration data nodes. If the client does not have the correct set of server features, then evaluation of if-feature statements by the client may be wrong. This causes real harm to interoperability, Our server implements the crypt-hash data type and implements the 3 features. The module is (correctly) listed in the 'module' list, because it is NOT used as an import-only module in our server. It is an implemented module. Still not sure what real problem exists here. > /Jan > Andy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
