Re: [yang-doctors] Design pattern: Reusable types in type specific modules

[Ebben Aries <[e-mail]>]

Thx Kent - it looks as though this introduces another method I didn't
account for.

A module can import these modules, assume the feature you are gating the
data-tree by is _not_ supported, the data-tree is suppressed -
groupings, identities, etc.. can all be leveraged still.  We still fall
into the category of how to express "implement" vs. "import-only" (It
would still fall into the latter category) and thus a reliance on YANG
library support.

If all reusable objects were to be peeled off into their own modules and
anything that defines a base container/list/leaf/leaf-list in others
(using from the distinct "types" modules), we then have a firmer
demarcation reducing the reliance on learning to what extent a module is
supported/not-supported

On 2024-02-28 12:55:29, Kent Watsen wrote:
> [External Email. Be cautious of content]
> 
> 
> Hi Ebben,
> 
> The client-server suite of drafts in NETCONF provide a number of general purpose modules that are expected to be used outside of the original purpose of defining a configuration model for NETCONF and RESTCONF servers.
> 
> My solution is to sprinkle if-feature statements everywhere so that implementations can easily turn off the parts they don’t want.   I hate deviations and hence hope this makes it so they’re unnecessary.
> 
> Hope it helps.
> 
> Kent
> 
> 
> > On Feb 9, 2024, at 11:20 AM, Ebben Aries <exa=[e-mail]> wrote:
> >
> > YANG Doctors,
> >
> > I'd like to understand if there has ever been motivation or guidance to
> > model authors to question if any types (typedefs, identities or even
> > groupings) they are bringing into domain specific work are to be
> > used/leveraged outside of the scope of their immediate model work and if
> > it's best to choose an alternate pattern to create domain specific types
> > modules.
> >
> > Outside of the obvious reusable global type modules (ietf-inet-types,
> > ietf-yang-types, ietf-routing-types, etc..), there are many published
> > modules that bring in reusable common types along side data-trees,
> > notifications, rpcs, actions.
> >
> > If another module wants to leverage any such types but the
> > implementation may not support all other constructs, this is where the
> > YANG library implement vs. import-only comes in however to a consumer,
> > this is often not well understood or mandated for workflows.  Another
> > solution here is to produce deviations which give another common
> > misperception and perceived abuse that support is advertised for a model
> > (or set of models due to sometimes vast dependency chains) then
> > completely negated since only a small subset of a type is the
> > dependency.
> >
> > Where do we stand on this topic and have we been nudging any authors to
> > question if their types should indeed get pulled back into specific
> > domain/global types modules?
> >
> > Thx
> >
> > /ebben
> >
> > _______________________________________________
> > yang-doctors mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang-doctors__;!!NEt6yMaO-gk!FYlIlfTPQeyXz2LZ2n8GM7dOPThXPRs46H9ZdhVgp3AR1SIcQGcqoZDyM6imaPBQM8mDxcQ68Q$
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang-doctors__;!!NEt6yMaO-gk!FYlIlfTPQeyXz2LZ2n8GM7dOPThXPRs46H9ZdhVgp3AR1SIcQGcqoZDyM6imaPBQM8mDxcQ68Q$