Re: [netmod] Does defining a feature require the module be implemented?

On Thu, May 19, 2022 at 12:05 AM Martin Björklund <mbj+ietf@4668.se> wrote:

> Kent Watsen <kent+ietf@watsen.net> 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
>