Re: [Teas] WG adoption poll: draft-busi-teas-te-types-update-02

Hi Tom,

> I recently reviewed teas-path-computation which is now slightly harder to
> follow.  It used to have encoding and switching in line, clear and obvious, but it
> was revised to import them as a grouping from teas-yang-te, making the I-D
> harder to follow.
>

I can see your concern about the readability when grouping are used. However you have spotted a case where we have faced the issue of not using a grouping: in an old version of path computation we had copied the encoding and switching definitions from ietf-te module (with the intention to have common definitions) and immediately went out of synch (achieving exactly the opposite of our intention) ...

Without using the grouping who is going to ensure that the same definitions in multiple YANG modules are being aligned?

IMHO, there is no perfect solution but the efforts to check and maintain alignment or to implement different variations would by far overcome the efforts of reading YANG code using grouping

Moreover, the grouping is already defined in ietf-te YANG model and used in the path computation YANG model.
Not moving it to ietf-te-types (as proposed in the draft) is not going to solve your concern about the readability of the YANG modules, but just causing additional troubles to those who wish to re-use it for other purposes and do not need to implement the ietf-te YANG model

Italo

> -----Original Message-----
> From: t petch <ietfa@btconnect.com>
> Sent: mercoledì 22 giugno 2022 11:08
> To: Lou Berger <lberger@labn.net>; TEAS WG <teas@ietf.org>
> Cc: TEAS WG Chairs <teas-chairs@ietf.org>
> Subject: Re: [Teas] WG adoption poll: draft-busi-teas-te-types-update-02
> 
> On 16/06/2022 12:53, Lou Berger wrote:
> > Hello,
> >
> > This email begins a 2-week adoption poll for:
> > https://datatracker.ietf.org/doc/draft-busi-teas-te-types-update/
> >
> > No IPR has been disclosed on this document
> 
> This is a large I-D.  It tells me that the changes from the RFC8776 are small, two
> in number, but I doubt that that will reduce the work needed to make it an
> RFC.  The RFC Editor will likely still go through it comma by comma while ADs
> who were not on the IESG when RFC8776 was approved will likely review it
> line-by-line (and find some further changes to be made).
> 
> One change is to add a grouping for encoding and switching.  This is presented
> as a step forward, a view I find debatable.  Groupings make data harder to find.
> Groupings in a foreign document make data much harder to find.  They may
> make sense when there is a well-defined 'something', e.g. worthy of an object
> class in a database.  I do not see that here, rather something that will save
> some authors a few lines of code.
> 
> I recently reviewed teas-path-computation which is now slightly harder to
> follow.  It used to have encoding and switching in line, clear and obvious, but it
> was revised to import them as a grouping from teas-yang-te, making the I-D
> harder to follow.
> 
> You are now proposing a third way to implement this concept, a grouping in
> teas-te-types.
> 
> I see a lot of work for a step backwards and so oppose adoption.
> 
> Tom Petch
> 
> > Please voice your support or objections to adoption on the list by the
> > end of the day (any time zone) July 1.
> >
> > Thank you,
> > Lou (as Co-chair)
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> > .
> >
> 