Re: Last Call: <draft-ietf-teas-yang-te-topo-15.txt> (YANG Data Model for Traffic Engineering (TE) Topologies) to Proposed Standard

["tom p." <[e-mail]>]

I just got a sight of where this I-D leads to and find it challenging.

This I-D provides a template in Appendix C for other technologies to use
to augment the base YANG module:

draft-ietf-ccamp-otn-topo-yang

is such a technology and the YANG module therein consists of about 90
statements of the form

  /* Augment label hop of route-include of connectivity-matrices (added)
*/
  augment "/nw:networks/nw:network/nw:node/tet:te/"
        + "tet:te-node-attributes/tet:connectivity-matrices/"
        + "tet:optimizations/tet:algorithm/tet:metric/"
        + "tet:optimization-metric/"
        + "tet:explicit-route-include-objects/"
        + "tet:route-object-include-object/"
        + "tet:type/tet:label/tet:label-hop/"
        + "tet:te-label/tet:technology" {
    when "../../../../../../../../../../../../../../"
       + "nw:network-types/tet:te-topology/"
       + "otntopo:otn-topology" {
      description "Augment OTN TE label";
    }
    description "OTN label.";
    case otn {  uses otn-types:otn-path-label; }
  }

The YANG tree diagram, which is 'used to provided a simplified graphical
representation of a data model' runs to 15 pages and is almost harder to
follow.

It does seem to me that something has gone wrong here, with the
capabilities of YANG or the way it is used or ...  My knowledge of YANG
is not enough to know whether or not there is a different approach in
this I-D which would make the augmenting module easier to understand
(e.g. a data tree of fewer than 20 levels, use of relative XPath paths
or replacing 'when' with 'if-feature') but it does seem that what we
have now is hard to review in a meaningful way.  Yes, tools can tell us
that the augmenting module is syntactically correct but whether or not
it does what is says on the tin I find very hard to form a view on.

Tom Petch


---- Original Message -----
From: "tom p." <[e-mail]>
To: "tom p." <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Wednesday, June 06, 2018 10:26 AM

> Further thoughts on -16 (as my previous comments included below are).
>
> What is the status of Appendix B?  I find this a thorny question.
> Appendices are usually regarded as not Normative, with a statement
> called for when it is otherwise.  This is a YANG module which non-NMDA
> servers will implement so that says it is Normative, to me.  On the
> other hand, the world is going NMDA - I do not know how fast - so this
> is more like Historic; or non-Normative?
>
> I do not know the answer but do know we can expect to see this several
> times, so I am thinking that some thought and guidance from an Ops AD
> would be valuable.
>
> IANA Considerations should have a
>       reference:    RFC XXXX
> for each module registered
>
> Additionally, my comments about the YANG module in the body of the
> document apply to Appendix B and C namely
> - [RFC ... looks wrong in a YANG module
> - import without reference
>
> Does the YANG module in Appendix C need a Copyright statement?
>
> Should the YANG module in Appendix C be registered?  It took a while
for
> the IETF to see the need to define formally such things as
> example.com
> so I am thinking it probably should be lest we get many different
> varieties in the wild.
>
> And I would like a Note to the RFC Editor asking them to update the
> dates with the date of publication especially since there are five
such
> dates rather than the usual two.
>
> Tom Petch
>
> ----- Original Message -----
> From: "tom p." <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Sent: Tuesday, June 05, 2018 6:01 PM
>
>
> > Lou et al
> >
> > I note that the YANG module in this I-D has Reference statements to
20
> > other RFC, which is good, but only one of the twenty appear in the
> > References for the I-D, which I think is not good, and needs to be
> > fixed.
> >
> > Also, some of the RFC which appear in Reference clauses of the YANG
> > module appear in [square brackets] e.g. [RFC6001] which I think
should
> > not be there.
> >
> > In the same vein, there are imports of four other YANG modules but
no
> > indication as to which RFC they can be found in - again, I think
that
> > that needs fixing with a Reference statement.
> >
> > A quick pass suggests the missing references are to
> > 1195 missing
> > 3209 missing
> > 3272 missing
> > 3471 missing
> > 3630 missing
> > 3785 missing
> > 4201 4202 4203 4206 all missing
> > 4872 missing
> > 5152 missing
> > 5212 missing
> > 5305 missing
> > 6001 missing
> > 6241 ok Norm
> > 7471 missing
> > 7752 missing
> > 7579 missing
> >
> > Russ's comment about Section 1.1 does not seem to have been
addressed.
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "The IESG" <[e-mail]>
> > To: "IETF-Announce" <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>;
> > <[e-mail]>; <[e-mail]>
> > Sent: Wednesday, May 16, 2018 3:40 PM
> >
> > > The IESG has received a request from the Traffic Engineering
> > Architecture and
> > > Signaling WG (teas) to consider the following document: - 'YANG
Data
> > Model
> > > for Traffic Engineering (TE) Topologies'
> > >   <draft-ietf-teas-yang-te-topo-15.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 2018-05-30. 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 YANG data model for representing,
> > retrieving
> > >    and manipulating Traffic Engineering (TE) Topologies. The model
> > >    serves as a base model that other technology specific TE
Topology
> > >    models can augment.
> > >
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
> > >
> > > IESG discussion can be tracked via
> > >
> https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ballot/
> > >
> > >
> > > No IPR declarations have been submitted directly on this I-D.
> > >
> > >
> > > The document contains these normative downward references.
> > > See RFC 3967 for additional information:
> > >     rfc5212: Requirements for GMPLS-Based Multi-Region and
> Multi-Layer
> > Networks (MRN/MLN) (Informational - IETF stream)
>