YANG Data Model for Traffic Engineering (TE) Topologies
draft-ietf-teas-yang-te-topo-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-07-24
|
22 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-01
|
22 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-04-28
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2020-03-04
|
22 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-12-06
|
22 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-10-31
|
Jenny Bui | Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-teas-yang-te-topo | |
2019-08-19
|
22 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Withdrawn' |
2019-08-19
|
22 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response |
2019-07-24
|
22 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-07-23
|
22 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-07-23
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-07-22
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-07-22
|
22 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-22
|
22 | (System) | RFC Editor state changed to MISSREF |
2019-07-22
|
22 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2019-07-19
|
22 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-07-19
|
22 | Cindy Morgan | IESG has approved the document |
2019-07-19
|
22 | Cindy Morgan | Closed "Approve" ballot |
2019-07-19
|
22 | Deborah Brungard | Ballot approval text was changed |
2019-06-19
|
22 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-22.txt |
2019-06-19
|
22 | (System) | New version approved |
2019-06-19
|
22 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu … Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu Shah |
2019-06-19
|
22 | Xufeng Liu | Uploaded new revision |
2019-06-13
|
21 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2019-06-13
|
21 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-06-12
|
21 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-06-12
|
21 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-06-12
|
21 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-06-12
|
21 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-06-12
|
21 | Warren Kumari | [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 … [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 |
2019-06-12
|
21 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-06-11
|
21 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-06-11
|
21 | Roman Danyliw | [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 … [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/ |
2019-06-11
|
21 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-06-11
|
21 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-06-10
|
21 | Éric Vyncke | [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 … [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 ;-) |
2019-06-10
|
21 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-05-31
|
21 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-05-31
|
21 | Amy Vezza | Set telechat returning item indication |
2019-05-31
|
21 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-05-24
|
21 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-05-23
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-23
|
21 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-21.txt |
2019-05-23
|
21 | (System) | New version approved |
2019-05-23
|
21 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu … Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Tarek Saad , Igor Bryskin , Himanshu Shah |
2019-05-23
|
21 | Xufeng Liu | Uploaded new revision |
2019-05-23
|
20 | Amy Vezza | Telechat date has been changed to 2019-06-13 from 2018-06-07 |
2019-05-23
|
20 | Deborah Brungard | Ballot has been issued |
2019-05-23
|
20 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-05-23
|
20 | Deborah Brungard | Created "Approve" ballot |
2019-05-23
|
20 | Deborah Brungard | Ballot writeup was changed |
2019-05-15
|
20 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-05-14
|
20 | Melinda Shore | Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Melinda Shore. Sent review to list. |
2019-05-13
|
20 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-05-13
|
20 | Sabrina Tanamal | (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 … (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 |
2019-05-03
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2019-05-03
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2019-05-02
|
20 | Russ Housley | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Russ Housley. Sent review to list. |
2019-05-01
|
20 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-05-01
|
20 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-05-01
|
20 | Cindy Morgan | 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 … 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. |
2019-05-01
|
20 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-05-01
|
20 | Cindy Morgan | Last call announcement was changed |
2019-05-01
|
20 | Cindy Morgan | Last call announcement was generated |
2019-05-01
|
20 | Deborah Brungard | Last call was requested |
2019-05-01
|
20 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested::AD Followup |
2019-05-01
|
20 | Deborah Brungard | Last call announcement was changed |
2019-04-18
|
20 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > 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. |
2019-04-18
|
20 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-04-18
|
20 | Lou Berger | IESG state changed to Publication Requested from AD is watching |
2019-04-13
|
20 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-13
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-04-13
|
20 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-20.txt |
2019-04-13
|
20 | (System) | New version approved |
2019-04-13
|
20 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah … 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 |
2019-04-13
|
20 | Xufeng Liu | Uploaded new revision |
2019-04-12
|
19 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > 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. |
2019-03-20
|
19 | Deborah Brungard | WG requested to be pulled from RFC Editor's to align with te-types. Needs to go via process again as technical change. |
2019-03-20
|
19 | Deborah Brungard | IESG state changed to AD is watching::Revised I-D Needed from AD is watching |
2019-03-07
|
19 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-03-06
|
19 | Deborah Brungard | Tag Holding for references cleared. |
2019-03-06
|
19 | Deborah Brungard | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2019-03-06
|
19 | Deborah Brungard | IESG state changed to AD is watching from RFC Ed Queue |
2019-02-11
|
19 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-19.txt |
2019-02-11
|
19 | (System) | New version approved |
2019-02-11
|
19 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2019-02-11
|
19 | Xufeng Liu | Uploaded new revision |
2018-07-09
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-07-09
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-07-05
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-29
|
18 | (System) | RFC Editor state changed to MISSREF |
2018-06-29
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-06-29
|
18 | (System) | Announcement was received by RFC Editor |
2018-06-29
|
18 | (System) | IANA Action state changed to In Progress |
2018-06-29
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2018-06-29
|
18 | Amy Vezza | IESG has approved the document |
2018-06-29
|
18 | Amy Vezza | Closed "Approve" ballot |
2018-06-29
|
18 | Amy Vezza | Ballot writeup was changed |
2018-06-29
|
18 | Deborah Brungard | Ballot approval text was changed |
2018-06-27
|
18 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-18.txt |
2018-06-27
|
18 | (System) | New version approved |
2018-06-27
|
18 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2018-06-27
|
18 | Xufeng Liu | Uploaded new revision |
2018-06-23
|
17 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-17.txt |
2018-06-23
|
17 | (System) | New version approved |
2018-06-23
|
17 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Xufeng Liu , Vishnu Beeram , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2018-06-23
|
17 | Xufeng Liu | Uploaded new revision |
2018-06-11
|
16 | Jonathan Hardwick | Closed request for Last Call review by RTGDIR with state 'No Response' |
2018-06-07
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-06-07
|
16 | Ignas Bagdonas | [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 … [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. |
2018-06-07
|
16 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-06-07
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Melinda Shore. |
2018-06-07
|
16 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-06-06
|
16 | Adam Roach | [Ballot comment] I agree with Warren's comment. ;-) |
2018-06-06
|
16 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-06-06
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-06-06
|
16 | Warren Kumari | [Ballot comment] In the “Trusting AD, ran out of time “ sense. |
2018-06-06
|
16 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-06-06
|
16 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-06-06
|
16 | Benjamin Kaduk | [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 … [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.)? |
2018-06-06
|
16 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-06-06
|
16 | Ben Campbell | [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 … [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). |
2018-06-06
|
16 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-06-06
|
16 | Alvaro Retana | [Ballot comment] Security Considerations: It is important to call out the fact that the sensitive information in the readable data nodes includes geolocation. |
2018-06-06
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-06-05
|
16 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-06-05
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-06-05
|
16 | Spencer Dawkins | [Ballot comment] I found myself wondering what the last sentence in - TE Topology may not be congruent to the routing topology (topology … [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. |
2018-06-05
|
16 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-05
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-06-05
|
16 | Igor Bryskin | New version available: draft-ietf-teas-yang-te-topo-16.txt |
2018-06-05
|
16 | (System) | New version approved |
2018-06-04
|
16 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah … 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 |
2018-06-04
|
16 | Igor Bryskin | Uploaded new revision |
2018-06-04
|
15 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-05-31
|
15 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-05-31
|
15 | Deborah Brungard | Ballot has been issued |
2018-05-31
|
15 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-05-31
|
15 | Deborah Brungard | Created "Approve" ballot |
2018-05-31
|
15 | Deborah Brungard | Ballot writeup was changed |
2018-05-30
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-05-25
|
15 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-05-23
|
15 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-05-23
|
15 | Sabrina Tanamal | (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 … (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 |
2018-05-18
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-05-18
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-05-17
|
15 | Russ Housley | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Russ Housley. Sent review to list. |
2018-05-17
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2018-05-17
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2018-05-17
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-05-17
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-05-16
|
15 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-05-16
|
15 | Amy Vezza | 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 … 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) |
2018-05-16
|
15 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-05-16
|
15 | Deborah Brungard | Placed on agenda for telechat - 2018-06-07 |
2018-05-16
|
15 | Deborah Brungard | Last call was requested |
2018-05-16
|
15 | Deborah Brungard | Ballot approval text was generated |
2018-05-16
|
15 | Deborah Brungard | Ballot writeup was generated |
2018-05-16
|
15 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2018-05-16
|
15 | Deborah Brungard | Last call announcement was generated |
2018-04-09
|
15 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2018-04-09
|
15 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2018-04-06
|
15 | Deborah Brungard | Requested Last Call review by RTGDIR |
2018-03-18
|
15 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > 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. |
2018-03-18
|
15 | Lou Berger | Responsible AD changed to Deborah Brungard |
2018-03-18
|
15 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-03-18
|
15 | Lou Berger | IESG state changed to Publication Requested |
2018-03-18
|
15 | Lou Berger | IESG process started in state Publication Requested |
2018-03-18
|
15 | Lou Berger | Changed consensus to Yes from Unknown |
2018-03-18
|
15 | Lou Berger | Intended Status changed to Proposed Standard from None |
2018-03-18
|
15 | Lou Berger | Changed document writeup |
2018-03-18
|
15 | Lou Berger | Notification list changed to Lou Berger <lberger@labn.net> |
2018-03-18
|
15 | Lou Berger | Document shepherd changed to Lou Berger |
2018-03-15
|
15 | Lou Berger | LC Completed (9/26/17): https://www.ietf.org/mail-archive/web/teas/current/msg02793.html |
2018-03-15
|
15 | Lou Berger | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set. |
2018-03-15
|
15 | Lou Berger | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-02-22
|
15 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-15.txt |
2018-02-22
|
15 | (System) | New version approved |
2018-02-22
|
15 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2018-02-22
|
15 | Xufeng Liu | Uploaded new revision |
2018-02-20
|
14 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-14.txt |
2018-02-20
|
14 | (System) | New version approved |
2018-02-20
|
14 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2018-02-20
|
14 | Xufeng Liu | Uploaded new revision |
2017-10-29
|
13 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-13.txt |
2017-10-29
|
13 | (System) | New version approved |
2017-10-29
|
13 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2017-10-29
|
13 | Xufeng Liu | Uploaded new revision |
2017-09-01
|
12 | Lou Berger | see https://www.ietf.org/mail-archive/web/teas/current/msg02760.html |
2017-09-01
|
12 | Lou Berger | IETF WG state changed to In WG Last Call from WG Document |
2017-09-01
|
12 | Lou Berger | IPR Call Complete: hshah@ciena.com, https://www.ietf.org/mail-archive/web/teas/current/msg02756.html sergio.belotti@nokia.com, https://www.ietf.org/mail-archive/web/teas/current/msg02759.html carlo.perocchio@ericsson.com, https://www.ietf.org/mail-archive/web/teas/current/msg02745.html |
2017-08-29
|
12 | Lou Berger | 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 … 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 |
2017-08-25
|
12 | Lou Berger | 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, … 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, |
2017-07-17
|
12 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-12.txt |
2017-07-17
|
12 | (System) | New version approved |
2017-07-17
|
12 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2017-07-17
|
12 | Xufeng Liu | Uploaded new revision |
2017-07-03
|
11 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-11.txt |
2017-07-03
|
11 | (System) | New version approved |
2017-07-03
|
11 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2017-07-03
|
11 | Xufeng Liu | Uploaded new revision |
2017-07-02
|
10 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-10.txt |
2017-07-02
|
10 | (System) | New version approved |
2017-07-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2017-07-02
|
10 | Xufeng Liu | Uploaded new revision |
2017-06-12
|
09 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-09.txt |
2017-06-12
|
09 | (System) | New version approved |
2017-06-12
|
09 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek … Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , Oscar de Dios , Igor Bryskin , Himanshu Shah , Tarek Saad |
2017-06-12
|
09 | Xufeng Liu | Uploaded new revision |
2017-05-24
|
08 | Mahesh Jethanandani | Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Mahesh Jethanandani. Sent review to list. |
2017-05-11
|
08 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Mahesh Jethanandani |
2017-05-11
|
08 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Mahesh Jethanandani |
2017-05-11
|
08 | Mehmet Ersue | Requested Last Call review by YANGDOCTORS |
2017-03-13
|
08 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-08.txt |
2017-03-13
|
08 | (System) | New version approved |
2017-03-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , Xufeng Liu , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah … 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 |
2017-03-13
|
08 | Xufeng Liu | Uploaded new revision |
2017-03-11
|
07 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-07.txt |
2017-03-11
|
07 | (System) | New version approved |
2017-03-11
|
07 | (System) | Request for posting confirmation emailed to previous authors: Vishnu Beeram , teas-chairs@ietf.org, Oscar de Dios , Igor Bryskin , Himanshu Shah , Xufeng Liu … 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 |
2017-03-11
|
07 | Xufeng Liu | Uploaded new revision |
2016-11-11
|
06 | Daniele Ceccarelli | Added to session: IETF-97: ccamp Mon-1550 |
2016-10-29
|
06 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-06.txt |
2016-10-29
|
06 | (System) | New version approved |
2016-10-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Igor Bryskin" , "Oscar de Dios" , "Xufeng Liu" , teas-chairs@ietf.org, "Himanshu Shah" , "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" |
2016-10-29
|
05 | Xufeng Liu | Uploaded new revision |
2016-07-08
|
05 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-05.txt |
2016-03-21
|
04 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-04.txt |
2016-03-20
|
03 | Xufeng Liu | New version available: draft-ietf-teas-yang-te-topo-03.txt |
2015-10-19
|
02 | Vishnu Beeram | New version available: draft-ietf-teas-yang-te-topo-02.txt |
2015-07-06
|
01 | Vishnu Beeram | New version available: draft-ietf-teas-yang-te-topo-01.txt |
2015-05-19
|
00 | Lou Berger | This document now replaces draft-liu-teas-yang-te-topo instead of None |
2015-05-09
|
00 | Tarek Saad | New version available: draft-ietf-teas-yang-te-topo-00.txt |