Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

[Tarek Saad <[e-mail]>]

Hi tom/all,

The authors of ID. draft-ietf-teas-yang-te-types discussed this further and decided to remove duplication from it (including the ODU identities). Those identities will be kept defined in draft-ietf-ccamp-layer1-types.

We've posted a new revision-10 for this and diffs are at:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-te-types-10.txt

Regards,
Tarek

On 6/12/19, 11:46 AM, "tom petch" <[e-mail]> wrote:

    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" <[e-mail]>
    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" <[e-mail]>
    > To: "tom petch" <[e-mail]>; <[e-mail]>; "Igor
    > Bryskin" <[e-mail]>
    > Cc: <[e-mail]>; <[e-mail]>;
    > <[e-mail]>; <[e-mail]>
    > 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"
    > <[e-mail] on behalf of [e-mail]> 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" <[e-mail]>
    > >     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
    > >     > [e-mail] mailing lists by 2019-05-16. Exceptionally,
    > comments may
    > >     be
    > >     > sent to [e-mail] 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dyang-2Dte-2Dtypes_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=MgJhvGt3mLwf8f9oWtdgerXDnDXzWE5pvU6BFj8r864&s=sTdVI3lRGKKmF89yGm2eFIv8r_KS-Dn_Ar-YQ-OtKRk&e= 
    > >     >
    > >     > IESG discussion can be tracked via
    > >     >
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dyang-2Dte-2Dtypes_ballot_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=MgJhvGt3mLwf8f9oWtdgerXDnDXzWE5pvU6BFj8r864&s=c4E4U0W3y8jCefYdsYmyyXDNIHRnmrJu_rteKNOqfP0&e= 
    > >     >
    > >     >
    > >     > No IPR declarations have been submitted directly on this I-D.
    > >     >
    > >     >
    > >     >
    > >     >
    > >
    > >     _______________________________________________
    > >     Teas mailing list
    > >     [e-mail]
    > >     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=MgJhvGt3mLwf8f9oWtdgerXDnDXzWE5pvU6BFj8r864&s=A1Ci3lsylJh4kVbFSx9zv21ELU9q5wsSx6lJ_fCQCTQ&e= 
    > >
    > >
    >
    >
    > ----------------------------------------------------------------------
    --
    > --------
    >
    >
    > > _______________________________________________
    > > Teas mailing list
    > > [e-mail]
    > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=MgJhvGt3mLwf8f9oWtdgerXDnDXzWE5pvU6BFj8r864&s=A1Ci3lsylJh4kVbFSx9zv21ELU9q5wsSx6lJ_fCQCTQ&e= 
    > >
    >