And now it would appear we have quadruplicate definitions with the advent of draft-ietf-ccamp-layer1-types which has a comprehensive, and different, set of ODU (upper case) types. Tom Petch ----- Original Message ----- From: "t.petch" <ietfa@xxxxxxxxxxxxx> Sent: Thursday, June 06, 2019 4:43 PM > Tarek > > You asked about my reference to definitions in triplicate which my later > response did not expand on. > > The three I was counting were this I-D, exisiting IANA registries (some > of > which are identical to this I-D, some not) and the LSR I-D > draft-ietf-isis-yang-isis-cfg > which contains definitions of switching capability which I see > overlapping a part of this I-D. I thought I saw an e-mail from > Stephane, > around Christmas, saying he would discuss this with other chairs but > cannot now find it so perhaps the wish was father to the thought. > > The LSR I-D is now in AD review on the LSR list and so may get more > attention. > > Tom Petch > > ----- Original Message ----- > From: "Tarek Saad" <tsaad.net@xxxxxxxxx> > To: "tom petch" <daedulus@xxxxxxxxxxxxx>; <ietf@xxxxxxxx>; "Igor > Bryskin" <Igor.Bryskin@xxxxxxxxxx> > Cc: <draft-ietf-teas-yang-te-types@xxxxxxxx>; <teas-chairs@xxxxxxxx>; > <teas@xxxxxxxx>; <db3546@xxxxxxx> > Sent: Wednesday, May 15, 2019 10:13 PM > Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> > (Traffic Engineering Common YANG Types) to Proposed Standard > > > > Hi Tom, > > > > Thanks for sharing your feedback. > > I'm attaching Igor's response on this topic -- which I share his same > opinion. > > Please see more comments inline from me [TS].. > > > > On 5/15/19, 7:16 AM, "Teas on behalf of tom petch" > <teas-bounces@xxxxxxxx on behalf of daedulus@xxxxxxxxxxxxx> wrote: > > > > The approach taken by this I-D worries me. > > > > It provides YANG identities for a wide range of values used in TE, > such > > as encoding types and switching capabilities; so far, so good. > > [TS]: As mentioned in abstract, the module is not strictly identities. > It is a collection of re-usable YANG groupings, types and identities. > > > > These definitions were needed, and were in a large part created by > > RFC3471, in 2003. When the management of GMPLS was specified, in > MIB > > modules, these definitions were put under IANA control and they > remain > > there to this day. They were updated by e.g. RFC8330 (February > 2018) > > and RFC8363 (May 2018) so these IANA registries are not some dusty > old > > relic but a current, living specification. > > > > These YANG definitions have much in common with the IANA SMI > registries > > but they are not the same. A comparison of e.g. switching > capabilities > > suggests that this YANG module is out-of-date compared with the > IANA SMI > > registry (as with RFC8330, RFC8363) and omits several values for > no > > stated reason ( the deprecated 2,3,4, 40 PBB-TE, 151 WSON-LSC). > > [TS]: it was not the intention to be exhaustive in covering all IANA > defined entities. However, the objective was to model enough that would > make TE feature (modelled in other modules) usable and to leverage the > power of YANG augmentation for any extensions that may not be covered in > a base model. Specifically, the authors favored the use of YANG > identities over enums to allow for the extensibility of augmentation. > > > > The approach taken by other WG has been to take a IANA registry > and > > provide a parallel YANG module under common IANA control as has > been > > done for e.g. interfaces with both MIB module and YANG module > being > > updated in parallel as appropriate. > > > > Here something seems to have gone wrong. We have a parallel set > of > > definitions not acknowledging the existing ones and being > out-of-date > > compared with the existing ones. > > > > Furthermore, some of these definitions are duplicated in the work > of the > > LSR WG giving us (at least) three definitions. > > [TS]: it would help to point to the duplication or thread that this > was discussed in. However, we believe that this document covers TE data > and hence LSR module(s) would need to eliminate duplication of any TE > data (if any).. LSR module can always import TE types to use the TE > definitions. > > > > I raised this issue before Christmas 2018 and was told that the > chairs > > of TEAS and LSR would get together and get back to me. Nothing > appears > > to have changed. > > > > In passing, IANA has separate SMI registries for e.g.LSP encoding, > > Switching Types and so on, which seems a sound engineering > approach, > > allowing more flexible evolution compared to the 60-page monolith > of > > this single YANG module. > > [TS]: In this effort, we've followed similar approach to RFC8294, > RFC6021. Etc.. Do you see the same concerns there too? > > > > Regards, > > Tarek > > > > ..Tom Petch > > > > ----- Original Message ----- > > From: "The IESG" <iesg-secretary@xxxxxxxx> > > Sent: Thursday, May 02, 2019 9:47 PM > > > > > The IESG has received a request from the Traffic Engineering > > Architecture and > > > Signaling WG (teas) to consider the following document: - > 'Traffic > > > Engineering Common YANG Types' > > > <draft-ietf-teas-yang-te-types-09.txt> as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final > > > comments on this action. Please send substantive comments to the > > > ietf@xxxxxxxx mailing lists by 2019-05-16. Exceptionally, > comments may > > be > > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of > > > the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document defines a collection of common data types and > > groupings > > > in YANG data modeling language. These derived common types > and > > > groupings are intended to be imported by modules that model > Traffic > > > Engineering (TE) configuration and state capabilities. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ > > > > > > IESG discussion can be tracked via > > > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ballot/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > ---------------------------------------------------------------------- -- > -------- > > > > _______________________________________________ > > Teas mailing list > > Teas@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/teas > > >
