Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[tom petch <[e-mail]>]

From: OPSAWG <[e-mail]> on behalf of Zhenghaomian <[e-mail]>
Sent: 04 June 2020 07:16

Hi, Joe, Qin,

The groupings in the types is understood to be used in multiple other modules. Considering about the potential ‘uses’ in other models, it may not be a matter for putting in a same type YANG or separate one.

A more challenging issue is to have a ‘right-fit’ types. If a types contain 100 typedef and identities, sometimes we will be in the dilemma whether we should import it as we may only use no more than 10 in it. In such case re-definition seems to be a waste but importation would be too much weight. It can be even worse if we start a new one, then redefine some of them and add more for extension.

Thoughts?

<tp>
It is a judgement call that is often wrong ie too much is included, too many of something or too many different somethings.  If in doubt, leave it out.  I have no problem with grouping being there but do want the grouping to be a meaningful building block.  As with writing software, I see a tendency to see two lines that appear twice and to say 'Quick, let's make it a subroutine (or macro or procedure ...)'  It needs to be something meaningful, like a 'start', 'end', 'step' or  choice of case for different layer four protocols or some such set.  But with YANG I would say that the grouping must be usable per se; if it requires an augmentation wherever it is used, then it should not be a common grouping - augmentation is a big barrier to comprehension in YANG (and much overused IMHO:-)

As to separate modules or one type/identity/enumeration/grouping module, again it is like software.  What is the likely evolution over, say, five years?  If they proceed in lockstep, then one module;  If parts are something that has been stable for years while other parts are in rapidly evolving technology that will be updated in six months, then split so that they can evolve independently; and one module may then be combined grouping and type.

And there is an option for IANA maintained modules, where updates do not require a new RFC, particularly suitable for registries with Expert Review; the reviewer deems an update is warranted and IANA updates the module.  Works well with enumeration.

Overall, code . DDL and the like are written once and used a hundred or a thousand times so consider the user coming to this a year or two hence - what is easier to understand, what harder to misunderstand/?  Stick to simplicity and consistency.

HTH
Tom Petch 






Best wishes,
Haomian

发件人: OPSAWG [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2020年6月4日 12:09
收件人: Joe Clarke (jclarke) <jclarke=[e-mail]>; SAMIER BARGUIL GIRALDO <[e-mail]>
抄送: [e-mail]
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

发件人: OPSAWG [mailto:[e-mail]] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO <[e-mail]<mailto:[e-mail]>>
抄送: [e-mail]<mailto:[e-mail]>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)


The module is available in the following PULL REQUEST: https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be included in types module,
section 4.3 of RFC8407 said:
“
4.13<https://tools.ietf.org/html/rfc8407#section-4.13>.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable grouping in the type modules, my impression is grouping that contain newly defined typedef and identities can be added into type modules, grouping in grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407