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

From: "tom p." <[email-masked]>
Date: Tue, 5 Jun 2018 18:01:27 +0100

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
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
> [email-masked] mailing lists by 2018-05-30. Exceptionally, comments may
be
> sent to [email-masked] 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)

---

From: "tom p." <[email-masked]>
Date: Wed, 6 Jun 2018 10:26:24 +0100

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." <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 05, 2018 6:01 PM

---

From: "tom p." <[email-masked]>
Date: Tue, 19 Jun 2018 12:11:36 +0100

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." <[email-masked]>
To: "tom p." <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 06, 2018 10:26 AM

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 19 Jun 2018 09:33:09 -0400

Hi Tom,

Agree what you said. We have brought this issue up in the NETMOD WG, but
our proposal got shot down.

https://mailarchive.ietf.org/arch/browse/netmod/?q=augment+grouping

We will try again later, but this is what we have for now.

Thanks,
- Xufeng

---

From: Xufeng Liu <[email-masked]>
Date: Sun, 24 Jun 2018 15:46:25 -0400

Hi Tom,

Thanks for pointing out these. We have posted

We have posted an undated version
*https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-17
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-17>* to include
the fixes for these.

Best regards,
- Xufeng

> 4201 4202 4203 4206 all missing
[Xufeng]: Fixed.

> Russ's comment about Section 1.1 does not seem to have been addressed.
[Xufeng]: Fixed.

---

From: Xufeng Liu <[email-masked]>
Date: Sun, 24 Jun 2018 16:15:08 -0400

Hi Tom,

> times, so I am thinking that some thought and guidance from an Ops AD

[Xufeng]: The current format is the result of long, back-and-forth
discussions among NETMOD and RGTWG working groups, and related ADs.
https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSIoH4gA-8M
For now, we use this convention, until a new one is agreed on.

> for each module registered

[Xufeng]: Fixed in revision -17.

> Does the YANG module in Appendix C need a Copyright statement?

[Xufeng]: For the example in Appendix C, we currently follow the format
from  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20, which
does not use Copyright statement.