YANG Data Model for Traffic Engineering (TE) Topologies
draft-ietf-teas-yang-te-topo-22

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu Shah

[Ballot comment]
I had the weirdest sense of deja-vu when reading this (on a plane, while jet-lagged) -- and then noticed that it was a returning item :-P

[Ballot comment]
(1) Section 4.2.  Per “The data model proposed in this document can be used to retrieve/represent/manipulate the customized TE Topology depicted in Figure 8b” this statement struck me as odd because aren’t all of the topologies depicted here supported with the modeling language?

(2) Section 4.2.  Per “Although an authorized client MAY receive a TE topology with the client ID field  matching some other client”, why would this happen?  Couldn’t this potentially leak customized TE information across clients?

(3) Section 5.9.  Per “When two or more templates specify values for the same configuration field, the value from the template with the highest priority is used”, is the highest priority 0 or 65535 (since priority is a uint16)?  The text doesn’t indicate whether the highest priority is a largest or smallest number.

(4) Editorial Nits
-- Section 3.4.  Missing word.  s/3.3/Section 3.3/

-- Section 4.2.  Typo.  s/-connectivit-/-connectivity-/

-- Section 4.2.  Editorial.  Why does “single-abstract-node-with-connectivit –matrix topology” use hyphens and “border_nodes_connected_via_mesh_of_abstract_links topology” use an underscore?

-- Section 4.2.  Typo.  s/Although a/Although an/

-- Section 5.6.  Typo.  s/cooresponding/corresponding/

[Ballot comment]
Thank you all for the work put into this document and the advanced ASCII-art pieces.

I have only a small nit (feel free to ignore).

== NITS ==

-- Section 3 --

I would suggest to expand TTP and LTP before using them in Figure 1 even if they are defined later in the text (I appreciate that space is limited on the picture).

Related to this, in section 6, TTP and LTP are expanded again ;-)

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu Shah

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-teas-yang-te-topo-20 and doesn't see any changes to the IANA actions that were reviewed in version -18. After this document was initially approved for publication in June 2018, we completed the actions listed below. When the new version of the document is approved, we will update the references associated with the following registrations to point to the most recent version of the document:

We've added the following entries to the IETF XML ns registry:

ID: yang:ietf-te-topology
URI: urn:ietf:params:xml:ns:yang:ietf-te-topology
https://www.iana.org/assignments/xml-registry/ns/yang/ietf-te-topology.txt
Reference: [RFC-ietf-teas-yang-te-topo-18]

ID: yang:ietf-te-topology-state
URI: urn:urn:ietf:params:xml:ns:yang:ietf-te-topology-state
https://www.iana.org/assignments/xml-registry/ns/yang/ietf-te-topology-state.txt
Reference: [RFC-ietf-teas-yang-te-topo-18]

Please see
https://www.iana.org/assignments/xml-registry


We've registered the following YANG Module Names:

Name: ietf-te-topology
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology
Prefix: tet
Reference: [RFC-ietf-teas-yang-te-topo-18]
Notes: [RFC-ietf-teas-yang-te-topo-18]'s module file will be posted upon document's publication as RFC.

Name: ietf-te-topology-state
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-state
Prefix: tet-s
Reference: [RFC-ietf-teas-yang-te-topo-18]
Notes: RFC-ietf-teas-yang-te-topo-18]'s module file will be posted upon document's publication as RFC.

Please see
https://www.iana.org/assignments/yang-parameters

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-05-15):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, draft-ietf-teas-yang-te-topo@ietf.org, Lou Berger , lberger@labn.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for Traffic Engineering (TE) Topologies) to Proposed Standard


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'
  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@ietf.org mailing lists by 2019-05-15. Exceptionally, comments may be
sent to iesg@ietf.org 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)

Note: This document was approved by the IESG in June, 2018 and with the RFC-Editor. The working group
requested to pull the document for a technical change to align with draft-ietf-teas-yang-te-types.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?
It contains a new YANG model and has impact on other on-wire behavior.

>Is this type of RFC indicated in the
> title page header?
Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
>
  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.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This work has occupied good attention within the WG as well as has been
coordinated with the I2RS, CCAMP, and MPLS WGs.  It is a the
foundational model for technology specific TE topology models.

This document  was in the RFC editor queue - it was pulled back to make a change informed by implementation.

>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification?

Authors from different organizations have stated that there are
implementations.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?
>

There has been reasonable discussion on list about the document both
before and as part of LC.  A YANG Doctor review has been conducted per
normal process.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area  Director?
>

Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I reviewed the document both as it was progressing and in it's final
form.  I also checked the output Yang Validation (via data tracker) and
ID nits returned no errors.

>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>

No

>
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
>

This document has been subject to wide review and was in the RFC editor queue - it was pulled back to make a change informed by implementation.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No current concerns.  This document  was in the RFC editor queue - it was pulled back to make a change informed by implementation.


>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes

>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Generally solid, with a reasonable number being interested in and
reviewing this work. No objections.

>
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>
No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

All errors are resolved.

>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
See above WRT YANG Doctors (review requested per process.)

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

>
> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

There are 1 normative reference to in progress work which is in publications requested state.

>
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
None.

>
> (16) Will publication of this document change the status of any
> existing RFCs?
No.

> Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?

N/A

> If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

N/A

>
>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>
The IANA section is consistent and matches the general form recommended
in RFC6087bis.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>
None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

I checked the output of Yang Validation (via data tracker) and online
ID nits.

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?
It contains a new YANG model and has impact on other on-wire behavior.

>Is this type of RFC indicated in the
> title page header?
Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
>
  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.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This work has occupied good attention within the WG as well as has been
coordinated with the I2RS, CCAMP, and MPLS WGs.  It is a the
foundational model for technology specific TE topology models.

This document  was in the RFC editor queue - it was pulled back to make a change informed by implementation.

>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification?

Authors from different organizations have stated that there are
implementations.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?
>

There has been reasonable discussion on list about the document both
before and as part of LC.  A YANG Doctor review has been conducted per
normal process.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area  Director?
>

Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I reviewed the document both as it was progressing and in it's final
form.  I also checked the output Yang Validation (via data tracker) and
ID nits returned no errors.

>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>

No

>
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
>

This document has been subject to wide review and was in the RFC editor queue - it was pulled back to make a change informed by implementation.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No current concerns.  This document  was in the RFC editor queue - it was pulled back to make a change informed by implementation.


>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes

>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Generally solid, with a reasonable number being interested in and
reviewing this work. No objections.

>
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>
No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

All errors are resolved.

>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
See above WRT YANG Doctors (review requested per process.)

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

>
> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

There are 1 normative reference to in progress work which is in publications requested state.

>
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
None.

>
> (16) Will publication of this document change the status of any
> existing RFCs?
No.

> Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?

N/A

> If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

N/A

>
>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>
The IANA section is consistent and matches the general form recommended
in RFC6087bis.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>
None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

I checked the output of Yang Validation (via data tracker) and online
ID nits.

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

[Ballot comment]
Focusing on YANG modules part only (as ran out of time for detailed review of reasoning behind model design) there does not appear to be any noticeable problems.

[Ballot comment]
Thanks to Alvaro for pointing out the specific considerations on the geolocation variables.

This document has a large number (6) of authors; https://www.rfc-editor.org/policy.html#policy.authlist
implies that justification is needed for more than 5 authors.

Section 3.4

I'm confused why the transitional TE link disappears once a normal
TE link abstracting away the layer transition appears -- is there no
longer potential to do layer transition at that node (e.g., to take
a different path in the server layer network) once a layer
transition is in use?

Section 8

I'm not sure I understand why the te:templates tree is not called
out as "sensitive" -- is it just the "template" nature?  Lots of
these look like things that could have detrimental impact if
modified in an actual live instance -- ID, bandwidth, type, etc., so
I mostly assume that it's just the templatey-ness, but don't quite
understand how that works.


There are a number of places where editorial attention would be beneficial; I only noted a
small subset of them.  One recurring theme is " is assigned with the  unique ID", which
might be more clearly phrased as "A  is assigned a unique ID within the scope of ".  Some
other specific items follow.

Section 1

  [...] There could be one or more TE Topologies present in a given
  Traffic Engineered system. The TE Topology is the topology on which
  path computational algorithms are run to compute Traffic Engineered
  Paths (TE Paths).

nit: If there could be more than one, it seems grammatically
improper to use the definite article "the" (without further
qualification) to refer to them.

Section 1.1

  Customized TE Topology: Customized TE Topology is a custom topology
  that is produced by a provider for a given Client. This topology
  typically augments the Client's Native TE Topology. Path
  computational algorithms aren't typically run on the Customized TE
  Topology; they are run on the Client's augmented Native TE Topology.

This text doesn't really help me tell the difference between the
"Client's augmented Native TE Topology" and the "Customized TE
Topology", which is the Client's Native TE Topology plus some
unspecified augmentation (that is apparently different from the one
used for path computation).

Section 2

  - Each TE Topological element has an information source associated
    with it. In some scenarios, there could be more than one
    information source associated with each topological element.

editorial: I'd suggest replacing the last "each" with "any given",
and maybe "has an" with "has at least one".

Section 3.3

  TE link is an element of a TE topology (presented as an edge on TE
  graph, arrows indicate one or both directions of the TE link).

(I don't see any arrows in Figure 1.)

  [...] TE link
  is connected to TE node, terminating the TE link via exactly one TE
  link termination point (LTP).

Even unidirectional links have a source and destination; presumably
both of those are attributes of the TE link?  Perhaps "for any given
node" should be more explicit?

Section 3.8

  [...] From the point of view of
  a potential TE path LLCL provides a list of valid TE links the TE
  path needs to start/stop on for the connection, taking the TE path,
  to be successfully terminated on the TTP in question.

nit: this could probably be reworded to be more clear, maybe:

%  From the point of view of usability in creating a TE path, the LLCL
%  provides a list of the TE links that would be valid path components
%  for paths involving the TTP in question.

Section 3.10

  is unique across all TE topologies provided by the same provider.  The
  client layer LIPs and the server layer TTPs associated within a given

Should that be "LTPs" instead of "LIPs"?

Section 4.4

  [...] maintain. For example, in addition to the merged TE topology depicted
  in the upper part of Figure 1, the client may merge the abstract TE

Figure 1 was long ago and does not seem relevant.  Was this supposed
to be Figure 9 or Figure 10?

Section 7

    grouping connectivity-label-restriction-list {
      description
        "List of abel restrictions specifying what labels may or may
          not be used on a link connectivity.";
      list label-restriction {
        key "index";
        description
          "List of abel restrictions specifying what labels may or may
            not be used on a link connectivity.";

presumably "label" rather than "abel" (twice)?

Another typo -- "speficied" for "specified" (also twice).
And "souruce" for "source" (twice)

Appendix C

Are there really supposed to be 63 occurrences of the string
"Attribute 11 for example technology" (i.e., with no "Attribute 1",
"Attribute 2", etc.)?

[Ballot comment]
Just some editorial comments:

- There is conflicting 2119/8174 boilerplate in the front material and in §1.1. I assume the latter is the correct boilerplate.

- The writing style makes heavy use of imbedded definitions and examples in parenthetical phrases. I personally find that creates quite a bit of readability friction. It would be easier to read if such things were split out into their own sentences.

- Some of the figures have legends, but most do not. It would be very helpful to include legends in those figures that depend on different line styles to convey meaning. (e.g. Figure 1).

[Ballot comment]
I found myself wondering what the last sentence in

  - TE Topology may not be congruent to the routing topology (topology
    constructed based on routing adjacencies) in a given TE System.
    There isn't always a one-to-one association between a TE-link and
    a routing adjacency. For example, the presence of a TE link
    between a pair of nodes doesn't necessarily imply the existence of
    a routing-adjacency between these nodes.

was saying about what IS implied between these nodes. I'm guessing, but this draft seems to assume a relatively low level amount of experience with traffic engineering, so I can imagine readers who could benefit from a word or two of explanation.

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-teas-yang-te-topo-15. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two, new namespaces will be registered as follows:

ID: yang:ietf-te-topology
URI: urn:ietf:params:xml:ns:yang:ietf-te-topology
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-te-topology-state
URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-state
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. If there is no expert designated for the registry, we will work with the IESG to have one assigned. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two, new YANG modules will be registered as follows:

Name: ietf-te-topology
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology
Prefix: tet
Module:
Reference: [ RFC-to-be ]

Name: ietf-te-topology-state
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-state
Prefix: tet-s
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entries for the registry values "Maintained by IANA?" for these new YANG modules?

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-30):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, draft-ietf-teas-yang-te-topo@ietf.org, Lou Berger , lberger@labn.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for Traffic Engineering (TE) Topologies) to Proposed Standard


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'
  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@ietf.org mailing lists by 2018-05-30. Exceptionally, comments may be
sent to iesg@ietf.org 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)

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?
It contains a new YANG model and has impact on other on-wire behavior.

>Is this type of RFC indicated in the
> title page header?
Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
>
  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.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This work has occupied good attention within the WG as well as has been
coordinated with the I2RS, CCAMP, and MPLS WGs.  It is a the
foundational model for technology specific TE topology models.

>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification?

Authors from different organizations have stated that there are
implementations.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?
>

There has been reasonable discusson on list about the document both
before and as part of LC.  A YANG Doctor review has been conducted per
normal process.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area  Director?
>

Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I reviewed the document both as it was progressing and in it's final
form.  I also checked the output Yang Validation (via data tracker) and
ID nits returned no errors.

>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>

No

>
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
>

Only the YANG Dr review, which has been completed.


> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

The sole concern found during shepherd review was addressed in the -15
version of the document.

>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, see
XXX

>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>
No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Generally solid, with a reasonable number being interested in and
reviewing this work. No objections.

>
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>
No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

ID nits is a bit slow running against this long document.  There is one
error that I have asked the authors to correct.

>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
See above WRT YANG Doctors (review requested per process.)

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

>
> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

There are 4 normative references to in progress work.  All are
progressing without any expected notable issues.

>
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
None.

>
> (16) Will publication of this document change the status of any
> existing RFCs?
No.

> Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?

N/A

> If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

N/A

>
>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>
The IANA section is consistent and matches the general form recommended
in RFC6087bis.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>
None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

I checked the output of Yang Validation (via data tracker) and online
ID nits.

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Waiting on:
hshah@ciena.com,
sergio.belotti@nokia.com,
carlo.perocchio@ericsson.com,

IPR comments received:
Xufeng Liu , https://www.ietf.org/mail-archive/web/teas/current/msg02732.html
Igor Bryskin , https://www.ietf.org/mail-archive/web/teas/current/msg02726.html
vbeeram@juniper.net, https://www.ietf.org/mail-archive/web/teas/current/msg02733.html
tsaad@cisco.com, https://www.ietf.org/mail-archive/web/teas/current/msg02735.html
OSCAR GONZALEZ DE DIOS  , https://www.ietf.org/mail-archive/web/teas/current/msg02739.html
Italo.Busi@huawei.com, https://www.ietf.org/mail-archive/web/teas/current/msg02734.html
"Beller, Dieter (Nokia - DE)" , https://www.ietf.org/mail-archive/web/teas/current/msg02728.html

Pre-LC IPR call:
https://www.ietf.org/mail-archive/web/teas/current/msg02725.html

Xufeng Liu ,
Igor Bryskin ,
vbeeram@juniper.net,
tsaad@cisco.com,
hshah@ciena.com,
OSCAR GONZALEZ DE DIOS  ,
Italo.Busi@huawei.com,
carlo.perocchio@ericsson.com,
"Beller, Dieter (Nokia - DE)" ,
sergio.belotti@nokia.com,

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad

Request for posting confirmation emailed to previous authors: Vishnu Beeram , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah , Xufeng Liu , Tarek Saad

Request for posting confirmation emailed to previous authors: "Igor Bryskin" , "Oscar de Dios" , "Xufeng Liu" , teas-chairs@ietf.org, "Himanshu Shah" , "Tarek Saad" , "Vishnu Beeram"