Requirements for Hitless MPLS Path Segment Monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-10-25
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-10-02
|
14 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-09-28
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-09-05
|
14 | (System) | RFC Editor state changed to EDIT |
2017-09-05
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-09-05
|
14 | (System) | Announcement was received by RFC Editor |
2017-09-05
|
14 | (System) | IANA Action state changed to No IC from In Progress |
2017-09-05
|
14 | (System) | IANA Action state changed to In Progress |
2017-09-05
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2017-09-05
|
14 | Cindy Morgan | IESG has approved the document |
2017-09-05
|
14 | Cindy Morgan | Closed "Approve" ballot |
2017-09-05
|
14 | Cindy Morgan | Ballot approval text was generated |
2017-09-05
|
14 | Deborah Brungard | Ballot writeup was changed |
2017-09-05
|
14 | Deborah Brungard | Ballot approval text was changed |
2017-09-01
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-09-01
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-09-01
|
14 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-14.txt |
2017-09-01
|
14 | (System) | New version approved |
2017-09-01
|
14 | (System) | Request for posting confirmation emailed to previous authors: Loa Andersson , Kaoru Arai , Alessandro D'Alessandro , Yoshinori Koike , Satoshi Ueno |
2017-09-01
|
14 | Alessandro D'Alessandro | Uploaded new revision |
2017-03-28
|
13 | Dave Sinicrope | (based on v12 of the document) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … (based on v12 of the document) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is indicated on the title page header, and is appropriate since this document specifies requirements for future work. (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 The MPLS transport profile (MPLS-TP) includes OAM functions which enable maintenance tools that may be used by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. Based on identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). Working Group Summary WG progress was relatively smooth with no controversy. Document Quality The document has been well reviewed by the WG, liaised to ITU-T SG15 as mentioned below, and updated accordingly. As a requirements document it does not specify any protocol to be implemented, but rather specifies requirements which will be used to guide future work. Personnel David Sinicrope is the current Document Shepherd. Deborah Brungard is the Responsible Area Director. David Sinicrope took over Document Shepherd responsibility from Ross Callon. (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. The document shepherd has reviewed the document, and the document has been updated in response to his comments. Huub van Helvoort has also done a grammatical review of the document. In addition Rtg Dir Review was performed and liaisons to ITU-T SG15 generated to inform them of the draft and its intent to describe different MPLS-TP OAM requirements those communicated from ITU-T previously. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (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. no additional review needed. (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. While no explicit concerns, it should be noted that the document entertains “analysis of existing MPLS-TP OAM mechanisms” and “provides requirements to guide development of new OAM tools” on a topic where requirements were established, led and communicated from ITU-T SG15. There has been liaison activity related to this topic and I-D dating back to 2010 with https://datatracker.ietf.org/liaison/917/. Continued open communication with ITU-T SG15 should be maintained to ensure continuity and migration from existing requirements and solutions. (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, all authors have confirmed they are not aware of any IPR that related to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed that reference this document. (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? Rough consensus. The document has been progressing slowly for quite a while and there was positive response to the WGLC with no objections albeit from a small handful of people, mostly from the author’s affiliations. (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 discontent or objection, just caution as noted by the comments regarding ITU-T above. (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. IDnits pointed to a few minor issues which should be corrected in v13. e.g., there is a reference in the abstract, [6371] which should be removed, so that it mentions RFC 6371 only. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. It should be noted that there are M#/Mandatory requirements made to informative references. (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? All references are to published RFCs. (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. No downrefs. Earlier versions of the document did have downrefs but it was clear that these should have been informative references, and the document was updated accordingly. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. not applicable. (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). There are no requests for IANA actions in this document. This is appropriate. (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. There are no requests for IANA actions in this document. (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. not applicable. |
2017-03-28
|
13 | Dave Sinicrope | (based on v12 of the document) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … (based on v12 of the document) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is indicated on the title page header, and is appropriate since this document specifies requirements for future work. (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 The MPLS transport profile (MPLS-TP) includes OAM functions which enable maintenance tools that may be used by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. Based on identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). Working Group Summary WG progress was relatively smooth with no controversy. Document Quality The document has been well reviewed by the WG, liaised to ITU-T SG15 as mentioned below, and updated accordingly. As a requirements document it does not specify any protocol to be implemented, but rather specifies requirements which will be used to guide future work. Personnel David Sinicrope is the current Document Shepherd. Deborah Brungard is the Responsible Area Director. David Sinicrope took over Document Shepherd responsibility from Ross Callon. (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. The document shepherd has reviewed the document, and the document has been updated in response to his comments. Huub van Helvoort has also done a grammatical review of the document. In addition Rtg Dir Review was performed and liaisons to ITU-T SG15 generated to inform them of the draft and its intent to describe different MPLS-TP OAM requirements those communicated from ITU-T previously. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (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. no additional review needed. (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. While no explicit concerns, it should be noted that the document entertains “analysis of existing MPLS-TP OAM mechanisms” and “provides requirements to guide development of new OAM tools” on a topic where requirements were established, led and communicated from ITU-T SG15. There has been liaison activity related to this topic and I-D dating back to 2010 with https://datatracker.ietf.org/liaison/917/. Continued open communication with ITU-T SG15 should be maintained to ensure continuity and migration from existing requirements and solutions. (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. (this is being reconfirmed for the latest revision) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed that reference this document. (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? Rough consensus. The document has been progressing slowly for quite a while and there was positive response to the WGLC with no objections albeit from a small handful of people, mostly from the author’s affiliations. (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 discontent or objection, just caution as noted by the comments regarding ITU-T above. (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. IDnits pointed to a few minor issues which should be corrected in v13. e.g., there is a reference in the abstract, [6371] which should be removed, so that it mentions RFC 6371 only. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. It should be noted that there are M#/Mandatory requirements made to informative references. (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? All references are to published RFCs. (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. No downrefs. Earlier versions of the document did have downrefs but it was clear that these should have been informative references, and the document was updated accordingly. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. not applicable. (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). There are no requests for IANA actions in this document. This is appropriate. (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. There are no requests for IANA actions in this document. (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. not applicable. |
2017-03-28
|
13 | Dave Sinicrope | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is indicated on the title page header, and is appropriate since this document specifies requirements for future work. (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 The MPLS transport profile (MPLS-TP) includes OAM functions which enable maintenance tools that may be used by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. Based on identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). Working Group Summary WG progress was relatively smooth with no controversy. Document Quality The document has been well reviewed by the WG and also as mentioned below, and updated accordingly. As a requirements document it does not specify any protocol to be implemented, but rather specifies requirements which will be used to guide future work. Personnel David Sinicrope is the current Document Shepherd, taking over from Ross Callon. Deborah Brungard is the Responsible Area Director. (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. The document shepherd has reviewed the document, and the document has been updated in response to his comments. At WG chair request Huub van Helvoort has also done a grammatical review of the document. In addition Rtg Dir Review was performed and liaisons to ITU-T SG15 generated to inform them of the draft and its intent to describe different MPLS-TP OAM requirements those communicated from ITU-T previously. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (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. no additional review needed. (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. While no explicit concerns, it should be noted that the document entertains “analysis of existing MPLS-TP OAM mechanisms” and “provides requirements to guide development of new OAM tools” on a topic where requirements were established, led and communicated from ITU-T SG15. There has been liaison activity related to this topic and I-D dating back to 2010 with https://datatracker.ietf.org/liaison/917/. Continued open communication with ITU-T SG15 should be maintained to ensure continuity and migration from existing requirements and solutions. (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. (this is being reconfirmed for the latest revision) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed that reference this document. (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? Rough consensus. The document has been progressing slowly for quite a while and there was positive response to the WGLC with no objections albeit from a small handful of people, mostly from the author’s affiliations. (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 discontent or objection, just caution as noted by the comments regarding ITU-T above. (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. IDnits pointed to a few minor issues which should be corrected in v12. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. It should be noted that there are M#/Mandatory requirements made to informative references. (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? All references are to published RFCs. (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. No downrefs. Earlier versions of the document did have downrefs but it was clear that these should have been informative references, and the document was updated accordingly. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. not applicable. (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). There are no requests for IANA actions in this document. This is appropriate. (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. There are no requests for IANA actions in this document. (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. not applicable. |
2017-03-22
|
13 | Jari Arkko | [Ballot comment] Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is … [Ballot comment] Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is wrong, or that the working group has knowingly chosen a particular path, or that some clarification or changes are needed in the document. But substantial comments need to be addressed in some fashion, and I don't feel we're quite there yet. But I also didn't see much discussion on my e-mail search, it is possible of course that discussion happened without me seeing it (I'm not on the MPLS WG list). All that being said, I held a Discuss position as a request for discussion, but I did not plan to hold on to it beyond the initial telechat, and I have now cleared (also considering that I'm off the IESG in a couple of days). |
2017-03-22
|
13 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2017-03-16
|
13 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-03-16
|
13 | Suresh Krishnan | [Ballot comment] Abstain for same reason as Alia. |
2017-03-16
|
13 | Suresh Krishnan | [Ballot Position Update] New position, Abstain, has been recorded for Suresh Krishnan |
2017-03-16
|
13 | Jari Arkko | [Ballot discuss] Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is … [Ballot discuss] Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is wrong, or that the working group has knowingly chosen a particular path, or that some clarification or changes are needed in the document. But substantial comments need to be addressed in some fashion, and I don't feel we're quite there yet. But I also didn't see much discussion on my e-mail search, it is possible of course that discussion happened without me seeing it (I'm not on the MPLS WG list). All that being said, this Discuss position is a request for discussion, but I do not plan to hold on to it beyond this telechat. |
2017-03-16
|
13 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2017-03-16
|
13 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-03-16
|
13 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-03-16
|
13 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-03-15
|
13 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-03-15
|
13 | Alia Atlas | [Ballot comment] I do not see the value of this document as an RFC - particularly absent any work on a solution after 5 years. |
2017-03-15
|
13 | Alia Atlas | [Ballot Position Update] New position, Abstain, has been recorded for Alia Atlas |
2017-03-15
|
13 | Benoît Claise | [Ballot comment] OPS DIR review from Jon Mitchell: Document is Ready with Nits. I share the concern that it's not totally clear upfront this is … [Ballot comment] OPS DIR review from Jon Mitchell: Document is Ready with Nits. I share the concern that it's not totally clear upfront this is a requirements versus solution document. There is also not much in the way of requirements of notification or how to signal back to the operator that a fault has occurred, but this may be OK if whatever solution would meet the requirements of this draft will include such text or rely on existing mechanisms discussed in RFC6371. |
2017-03-15
|
13 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-03-14
|
13 | Mirja Kühlewind | [Ballot comment] I don't see a value in publishing this document in the RFC series. Btw. the shepherd write up still says this doc is … [Ballot comment] I don't see a value in publishing this document in the RFC series. Btw. the shepherd write up still says this doc is standards track. Minor comments: - The classification into M(andatory) and O(ptional) is not consistent with the use of MUST and SHOULD. - The first sentence in the intro should use a lower case 'must'. - Sections 2.2 and 5. could be removed. |
2017-03-14
|
13 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2017-03-14
|
13 | Mirja Kühlewind | [Ballot comment] I don't see a value in publishing this document in the RFC series. Btw. the sherpherd write up still says this doc is … [Ballot comment] I don't see a value in publishing this document in the RFC series. Btw. the sherpherd write up still says this doc is standards track. Minor comments: - The classification into M(andatory) and O(ptional) is not consistent with the use of MUST and SHOULD. - The first sentence in the intro should use a lower case 'must'. - Sections 2.2 and 5. could be removed. |
2017-03-14
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-03-14
|
13 | Stewart Bryant | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list. |
2017-03-14
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2017-03-13
|
13 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-03-09
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2017-03-09
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2017-03-08
|
13 | Deborah Brungard | Changed consensus to Yes from Unknown |
2017-03-08
|
13 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-03-08
|
13 | Deborah Brungard | Ballot has been issued |
2017-03-08
|
13 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-03-08
|
13 | Deborah Brungard | Created "Approve" ballot |
2017-03-08
|
13 | Deborah Brungard | Ballot writeup was changed |
2017-03-08
|
13 | Deborah Brungard | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This is indicated on the title page header, and is appropriate since this document specifies requirements for future work. (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 The MPLS transport profile (MPLS-TP) includes OAM functions which enable maintenance tools that may be used by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. Based on identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). Working Group Summary WG progress was smooth with no controversy. Document Quality The document has been well reviewed by the WG and also as mentioned below, and updated accordingly. As a requirements document it does not specify any protocol to be implemented, but rather specifies requirements which will be used to guide future work. Personnel Ross Callon was initially the Document Shepherd, it is now David Sinicrope. Deborah Brungard is the Responsible Area Director. (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. The document shepherd has reviewed the document, and the document has been updated in response to his comments. At WG chair request Huub van Helvoort has also done a grammatical review of the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (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. no additional review needed. (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 concerns. (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 IPR disclosures have been filed that reference this document. (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? Solid consensus. The document has been stable for quite a while (except for editorial improvements) and there was significant positive response to the WGLC with 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. IDnits was completely clean, with no issues found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (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? All references are to published RFCs. (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. No downrefs. Earlier versions of the document did have downrefs but it was clear that these should have been informative references, and the document was updated accordingly. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. not applicable. (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). There are no requests for IANA actions in this document. This is appropriate. (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. There are no requests for IANA actions in this document. (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. not applicable. |
2017-03-08
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-03-08
|
13 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-13.txt |
2017-03-08
|
13 | (System) | New version approved |
2017-03-08
|
13 | (System) | Request for posting confirmation emailed to previous authors: Loa Andersson , Kaoru Arai , Alessandro D'Alessandro , Yoshinori Koike , Satoshi Ueno |
2017-03-08
|
13 | Alessandro D'Alessandro | Uploaded new revision |
2017-03-07
|
12 | Jon Mitchell | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jon Mitchell. Sent review to list. |
2017-03-03
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-03-02
|
12 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tero Kivinen. |
2017-02-28
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-02-28
|
12 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mpls-tp-temporal-hitless-psm-12, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mpls-tp-temporal-hitless-psm-12, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber Lead IANA Services Specialist PTI |
2017-02-28
|
12 | Stewart Bryant | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Stewart Bryant. Sent review to list. |
2017-02-23
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2017-02-23
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2017-02-23
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2017-02-23
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2017-02-20
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-02-20
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-02-17
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-02-17
|
12 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, db3546@att.com, mpls@ietf.org, "David Sinicrope" , mpls-chairs@ietf.org, … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, db3546@att.com, mpls@ietf.org, "David Sinicrope" , mpls-chairs@ietf.org, david.sinicrope@ericsson.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Hitless path segment monitoring) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Hitless path segment monitoring' as Informational RFC 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 2017-03-03. 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 One of the most important OAM capabilities for transport network operation is fault localisation. An in-service, on-demand segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between end points. However, the current segment monitoring approach defined for MPLS (including the transport profile (MPLS-TP)) in RFC 6371 [RFC6371] has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support a Hitless Path Segment Monitoring (HPSM). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-02-17
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-02-17
|
12 | Cindy Morgan | Last call announcement was generated |
2017-02-17
|
12 | Deborah Brungard | Last call was requested |
2017-02-17
|
12 | Deborah Brungard | Last call announcement was generated |
2017-02-17
|
12 | Deborah Brungard | Intended Status changed to Informational from Proposed Standard |
2017-02-17
|
12 | Deborah Brungard | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2017-02-17
|
12 | Deborah Brungard | Placed on agenda for telechat - 2017-03-16 |
2017-02-17
|
12 | Deborah Brungard | Last call was requested |
2017-02-17
|
12 | Deborah Brungard | Ballot approval text was generated |
2017-02-17
|
12 | Deborah Brungard | Ballot writeup was generated |
2017-02-17
|
12 | Deborah Brungard | IESG state changed to Last Call Requested from AD is watching |
2017-02-17
|
12 | Deborah Brungard | Last call announcement was generated |
2017-02-01
|
12 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-12.txt |
2017-02-01
|
12 | (System) | New version approved |
2017-02-01
|
12 | (System) | Request for posting confirmation emailed to previous authors: "Alessandro D'Alessandro" , "Satoshi Ueno" , "Kaoru Arai" , "Loa Andersson" , "Yoshinori Koike" |
2017-02-01
|
12 | Alessandro D'Alessandro | Uploaded new revision |
2016-11-30
|
11 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-11.txt |
2016-11-30
|
11 | (System) | New version approved |
2016-11-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Alessandro D'Alessandro" , "Satoshi Ueno" , "Kaoru Arai" , "Loa Andersson" , "Yoshinori Koike" |
2016-11-30
|
11 | Alessandro D'Alessandro | Uploaded new revision |
2016-07-21
|
10 | Loa Andersson | Notification list changed to draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, "David Sinicrope" <david.sinicrope@ericsson.com> from draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org |
2016-07-21
|
10 | Loa Andersson | Document shepherd changed to David Sinicrope |
2016-05-31
|
10 | Loa Andersson | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-10.txt |
2016-05-27
|
09 | Deborah Brungard | IESG state changed to AD is watching from Expert Review |
2016-05-27
|
09 | Deborah Brungard | Document has been revised significantly based on Routing Area Directorate review and AD review. It will need review by the Working Group and another WG … Document has been revised significantly based on Routing Area Directorate review and AD review. It will need review by the Working Group and another WG Last Call. |
2016-05-27
|
09 | Deborah Brungard | Tag Revised I-D Needed - Issue raised by AD set. |
2016-05-27
|
09 | Deborah Brungard | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2016-04-07
|
09 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Not Ready. Reviewer: David Sinicrope. |
2016-03-15
|
09 | Deborah Brungard | IESG state changed to Expert Review from AD Evaluation |
2016-03-02
|
09 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to David Sinicrope |
2016-03-02
|
09 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to David Sinicrope |
2016-02-17
|
09 | Deborah Brungard | IESG state changed to AD Evaluation from Publication Requested |
2015-12-20
|
09 | Ross Callon | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This is indicated on the title page header, and is appropriate since this document specifies requirements for future work. (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 The MPLS transport profile (MPLS-TP) includes OAM functions which enable maintenance tools that may be used by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. Based on identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). Working Group Summary WG progress was smooth with no controversy. Document Quality The document has been well reviewed by the WG and also as mentioned below, and updated accordingly. As a requirements document it does not specify any protocol to be implemented, but rather specifies requirements which will be used to guide future work. Personnel Ross Callon is the Document Shepherd. Deborah Brungard is the Responsible Area Director. (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. The document shepherd has reviewed the document, and the document has been updated in response to his comments. At WG chair request Huub van Helvoort has also done a grammatical review of the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (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. no additional review needed. (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 concerns. (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 IPR disclosures have been filed that reference this document. (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? Solid consensus. The document has been stable for quite a while (except for editorial improvements) and there was significant positive response to the WGLC with 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. IDnits was completely clean, with no issues found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (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? All references are to published RFCs. (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. No downrefs. Earlier versions of the document did have downrefs but it was clear that these should have been informative references, and the document was updated accordingly. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. not applicable. (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). There are no requests for IANA actions in this document. This is appropriate. (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. There are no requests for IANA actions in this document. (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. not applicable. |
2015-12-20
|
09 | Ross Callon | Responsible AD changed to Deborah Brungard |
2015-12-20
|
09 | Ross Callon | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2015-12-20
|
09 | Ross Callon | IESG state changed to Publication Requested |
2015-12-20
|
09 | Ross Callon | IESG process started in state Publication Requested |
2015-12-20
|
09 | Ross Callon | Notification list changed to draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org |
2015-12-20
|
09 | Ross Callon | Intended Status changed to Proposed Standard from Informational |
2015-12-20
|
09 | Ross Callon | Changed document writeup |
2015-12-18
|
09 | Ross Callon | Changed document writeup |
2015-12-18
|
09 | Ross Callon | Changed document writeup |
2015-12-18
|
09 | Ross Callon | Changed document writeup |
2015-12-18
|
09 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-09.txt |
2015-12-14
|
08 | Ross Callon | Changed document writeup |
2015-12-14
|
08 | Ross Callon | Changed document writeup |
2015-12-14
|
08 | Ross Callon | Changed document writeup |
2015-12-14
|
08 | Ross Callon | Changed document writeup |
2015-12-02
|
08 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-08.txt |
2015-11-15
|
07 | Ross Callon | passed WGLC. Waiting for editorial review. |
2015-11-15
|
07 | Ross Callon | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2015-11-01
|
07 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2015-07-29
|
07 | Robert Sparks | Manually set state back to "Active" from "Replaced" (further correction to the error resulting from the submission code bug) |
2015-07-22
|
07 | Robert Sparks | Removed the "draft replaces itself" relationship introduced by a submission form bug. |
2015-07-22
|
07 | (System) | This document now replaces draft-koike-mpls-tp-temporal-hitless-psm, draft-ietf-mpls-tp-temporal-hitless-psm instead of draft-koike-mpls-tp-temporal-hitless-psm |
2015-07-22
|
07 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-07.txt |
2015-06-14
|
06 | Ross Callon | Tag AD Followup cleared. |
2015-06-14
|
06 | Ross Callon | IETF WG state changed to WG Document from Waiting for WG Chair Go-Ahead |
2015-02-27
|
06 | Alessandro D'Alessandro | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-06.txt |
2014-01-31
|
05 | Yoshinori Koike | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-05.txt |
2013-10-21
|
04 | Loa Andersson | Intended Status changed to Informational from None |
2013-10-21
|
04 | Yoshinori Koike | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-04.txt |
2013-09-07
|
03 | Martin Vigoureux | Document shepherd changed to Ross Callon |
2013-05-07
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-07
|
03 | Amy Vezza | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-03.txt |
2013-04-02
|
02 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2013-04-02
|
02 | Loa Andersson | Annotation tag Revised I-D Needed set. Annotation tag Other - see Comment Log cleared. |
2013-03-15
|
02 | Loa Andersson | Annotation tag Other - see Comment Log set. Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
2013-03-15
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2013-03-15
|
02 | Loa Andersson | IETF WG state changed to WG Document from In WG Last Call |
2013-03-15
|
02 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2013-03-14
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2012-11-08
|
02 | Loa Andersson | WG Last Call - there were wglc comments that need to be resolved. A revised ID is needed. |
2012-11-08
|
02 | Loa Andersson | WGLC will end April 2nd. |
2012-11-08
|
02 | Loa Andersson | WG Last call ends April 2, 2013. |
2012-11-08
|
02 | Loa Andersson | The co-authors are working on addressing wglc comments. |
2012-11-08
|
02 | Loa Andersson | WGLC closes April 2, 2013 |
2012-11-08
|
02 | Yoshinori Koike | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-02.txt |
2012-07-16
|
01 | Yoshinori Koike | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-01.txt |
2012-03-27
|
00 | Stephanie McCammon | New version available: draft-ietf-mpls-tp-temporal-hitless-psm-00.txt |