Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
draft-ietf-mpls-lsp-ping-relay-reply-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-01-13
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-01-08
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-12-01
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-10-19
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-10-16
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-10-16
|
11 | (System) | RFC Editor state changed to EDIT |
2015-10-16
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-10-16
|
11 | (System) | Announcement was received by RFC Editor |
2015-10-16
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-10-15
|
11 | (System) | IANA Action state changed to In Progress |
2015-10-15
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-10-15
|
11 | Cindy Morgan | IESG has approved the document |
2015-10-15
|
11 | Cindy Morgan | Closed "Approve" ballot |
2015-10-15
|
11 | Cindy Morgan | Ballot approval text was generated |
2015-10-15
|
11 | Cindy Morgan | Ballot writeup was changed |
2015-10-15
|
11 | Cindy Morgan | Ballot approval text was generated |
2015-10-15
|
11 | Cindy Morgan | Ballot writeup was changed |
2015-10-15
|
11 | Deborah Brungard | Ballot approval text was changed |
2015-10-14
|
11 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@ietf.org to (None) |
2015-10-09
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed. Reviewer: Carlos Pignataro. |
2015-10-08
|
10 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2015-10-05
|
10 | Lizhong Jin | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-10-05
|
11 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-11.txt |
2015-10-01
|
10 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-10-01
|
10 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-10-01
|
10 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-10-01
|
10 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-09-30
|
10 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-09-30
|
10 | Stephen Farrell | [Ballot comment] - 3.2: The description of the destination address offset isn't clear to me. If this is some common thing in MPLS though, that's … [Ballot comment] - 3.2: The description of the destination address offset isn't clear to me. If this is some common thing in MPLS though, that's fine. If not, maybe it'd be worth being clearer here. (It does become clear later though, so this is a nit.) |
2015-09-30
|
10 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-09-29
|
10 | Alvaro Retana | [Ballot comment] I have some comments/questions: 1. TBD2 is the Relay Node Address Stack TLV Type. There seems to be some confusion in the text: … [Ballot comment] I have some comments/questions: 1. TBD2 is the Relay Node Address Stack TLV Type. There seems to be some confusion in the text: Section 4.2. (Receiving an Echo Request) says that the "Type of the Relay Node Address Stack TLV is chosen from the range 32768 to 49161…” giving the impression that any value can be used, while 8.2. (New TLV) in the IANA Considerations says that a "suggested value should be assigned” giving me the impression that the assignment is just a suggestion (and somehow reinforcing the text in 4.2), but the original definition in 3.2. (Relay Node Address Stack) simply says that the "value should be assigned by IANA”. Assuming that you simply want an assignment and that it would be what is used, please clean the text up; I suggest just referring to the value as TBD2 (in 4.2 and 8.2) and explicitly including the text about the assignment and the range (from 3.2) in 8.2. 2. Section 4.1. (Sending an Echo Request) says that the "Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required”. How does the initiator know that it needs the functionality? 3. Section 4.2. (Receiving an Echo Request) "A second or more address entries MAY also be added if necessary, depending on implementation.” Isn’t this document defining how the implementation should work? What are the cases where these additional entries may be added? |
2015-09-29
|
10 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-29
|
10 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-09-29
|
10 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-09-28
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-09-28
|
10 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-09-28
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-09-28
|
10 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. The security review from 6 months ago hasn't been fully addressed in the draft and I … [Ballot comment] Thanks for your work on this draft. The security review from 6 months ago hasn't been fully addressed in the draft and I think it would be helpful to do so. There were responses given on list, but corresponding updates didn't happen for all of the comments. https://www.ietf.org/mail-archive/web/secdir/current/msg05301.html For the first comment, the response was that this mechanism does not deprecate use of "Echo Reply". The language in the first paragraph of section 3 should be made clear on that point. For the second comment: s4.1: Is the outermost label allowed to be set to 255 to support the “ping” mode or must it always be set to 1, 2, etc. to support “traceroute" mode - as described in RFC 4379 s4.3? I know s5 is just an example but it really looks like this extension is just supposed to be for fault isolation. The response via email says it is possible to set it to 255, could this be made clear in the draft? The third comment was addressed, thank you. It was also good to see the security considerations cover path discovery as well as DoS related attacks. Thanks for that! |
2015-09-28
|
10 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-09-27
|
10 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-09-26
|
10 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-25
|
10 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Andrew Malis. |
2015-09-25
|
10 | Alia Atlas | [Ballot comment] 1) In Sec 2 above Figure 1 "1) Note that throughout the document, routable address means that it is possible to route … [Ballot comment] 1) In Sec 2 above Figure 1 "1) Note that throughout the document, routable address means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS." Shouldn't that be "by the IGP and BGP (or EGP) operating in the AS"?? |
2015-09-25
|
10 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-09-25
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-09-24
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-09-24
|
10 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mpls-lsp-ping-relay-reply-10. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mpls-lsp-ping-relay-reply-10. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, in the Message Types subregistry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a single new message type will be registered from the "Standards Action" range (0-191) as follows: Value: [ TBD-at-Registration ] Meaning: MPLS Relayed Echo Reply Reference: [ RFC-to-be ] Second, in the TLVs subregistry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a single new TLV will be registered from the "Standards Action" range (32768-49161) as follows: Type: [ TBD-at-Registration ] TLV Name: Relay Node Address Stack TLV Reference: [ RFC-to-be ] Sub-TLV Registry: Third, in the Return Codes subregistry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a single new return code will be registered from the "Standards Action" range (0-191) as follows: Value: [ TBD-at-Registration ] Meaning: One or more TLVs not returned due to MTU size Reference: [ RFC-to-be ] 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 only to confirm what actions will be performed. |
2015-09-24
|
10 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Sean Turner |
2015-09-24
|
10 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Sean Turner |
2015-09-23
|
10 | Deborah Brungard | Placed on agenda for telechat - 2015-10-01 |
2015-09-23
|
10 | Deborah Brungard | Ballot has been issued |
2015-09-23
|
10 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2015-09-23
|
10 | Deborah Brungard | Created "Approve" ballot |
2015-09-23
|
10 | Deborah Brungard | Changed consensus to Yes from Unknown |
2015-09-17
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2015-09-17
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2015-09-17
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2015-09-17
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2015-09-14
|
10 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Andrew Malis |
2015-09-14
|
10 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Andrew Malis |
2015-09-11
|
10 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Relayed Echo Reply mechanism for … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Relayed Echo Reply mechanism for LSP Ping) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Relayed Echo Reply mechanism for LSP Ping' 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 2015-09-25. 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 In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1945/ https://datatracker.ietf.org/ipr/828/ |
2015-09-11
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-09-11
|
10 | Amy Vezza | Last call announcement was generated |
2015-09-11
|
10 | Deborah Brungard | Last call was requested |
2015-09-11
|
10 | Deborah Brungard | IESG state changed to Last Call Requested from AD Evaluation |
2015-09-09
|
10 | Deborah Brungard | IESG state changed to AD Evaluation from Publication Requested |
2015-07-18
|
10 | Loa Andersson | The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping … The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping draft-ietf-mpls-lsp-ping-relay-reply-03 is published as an RFC on the Standards Track. Note: On the reuesst from the co-author this document was sent back to the wg for "further work" very late in the approval process (document was in IETF Last Call). The document has then been updated and re-reviewed. Most of the earlier Shepherds Write-up stands. Where changes has been made this clearly marked. (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? We request that the document is published as a Proposed Standard. This document specifies protocol extensions to LSP Ping to enable a replying LSR to have the capability to relay Echo Response messages. Since the LSP Ping protocol is extended this is a Standards Track document. The document header says Standards Track. (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 When the first version of RFC 4379 (a.k.a LSP Ping) were deployed it was quickly understood that in some inter autonomous system (AS) and inter-area deployments a LSR replying to an MPLS Echo request LSR may not have the available route to the initiator. The Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation. This document describes extensions to LSP Ping mechanism to enable LSRs to have the capability to relay the Echo Response by a set of routable intermediate nodes. This document updates RFC 4379. 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? Nothing out of the ordinary. 2015-07-09: Pulling a document back this late in the process is certainly "out of the ordinary". The updates to the draft were discussed at the working group meeting in Dallas, and an MPLS-RT review were done at about the same time and the wglc was done. The effect is that the document (now) has been very well reviewed and has good support in the working. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? 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? We know of implementations and deployments of this specification. We also have indications that vendors have plans to implement. , A poll for implementations has been sent to the working group, and the Shepherd Write-Up will be updated as we receive more information. 2015-07-09: We started a new implementation poll during the wglc, the result is about the same, but the "intention to implement" is slightly strong. Also one of the implementers stated that they were in the process of updating their implementation to match the specification as it stands after the update. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document Shepherd Deborah Brungard is the responsible AD (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 is convinced that the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, there has been a good debate on this draft, most of it taking place when the individual the preceded the working group document was reviewed by the MPLS review team. (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 such reviews are necessary. (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 such 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. All the authors has replied to the IPR poll, stating that they are not aware of any other IPR than what is already disclosed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure against this document. The terms quoted are such that it has not generated any discussion, we have accepted such terms for along term. (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? The LSP Ping is a very commonly deployed protocol, the extensions described/specified in this document has been identified as necessary by several operators and implementers. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Update to the Shepherds Writeup (for version -04) - marked Oct 2014. The ID nits points out that the pre-5378 boiler plate is used, however the shepherd does not think this is necessary, since both the original co-authors of RFC 4379 have granted the BCP78 rights to the IETF Trust. 2015-07-09: The discussion the pre-5378 boiler plate resulted in that the we to not use the the boiler-plate. There are no ad verbatim quotes from RFC 4379. The document itself is a merger of two individual drafts. The first is pre-5378, but both authors has announced that they are willing to assign there rights to the IETF trust. The other document is post-5378. Oct 2014: The statement above is not correct, it it true that we had the two original co-authors agree to grant their BCP 78 rights to the IANA trust, however after further investigation there are many more people that would need to do the same. We have done an effort to reach all of them, but did not succeed, so the pre-5378 boilet plate should be used in this document. Oct 2014 / 2015-07-09: The nits tool find one instance of non-RFC2606-compliant FQDNs in the document.. As far as the shepherd understands this is generated by one of the authors mail address. No other nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes - the references are correctly split up in normative and informative. (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 normative references are to existing RFCs. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (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. There are no RFCs for which the status is changed, but RFC 4379 is updated, this is discussed in the abstract and in the Introduction. (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 (and the info related to in the draft) is well and clearly written, a new message type is requested. The shepherd has reviewed the IANA section several times. (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. No such new registries. (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. Non such automated checks necessary. |
2015-07-18
|
10 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-07-18
|
10 | Loa Andersson | IESG state changed to Publication Requested from AD is watching |
2015-07-09
|
10 | Loa Andersson | The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping … The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping draft-ietf-mpls-lsp-ping-relay-reply-03 is published as an RFC on the Standards Track. Note: On the reuesst from the co-author this document was sent back to the wg for "further work" very late in the approval process (document was in IETF Last Call). The document has then been updated and re-reviewed. Most of the earlier Shepherds Write-up stands. Where changes has been made this clearly marked. (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? We request that the document is published as a Proposed Standard. This document specifies protocol extensions to LSP Ping to enable a replying LSR to have the capability to relay Echo Response messages. Since the LSP Ping protocol is extended this is a Standards Track document. The document header says Standards Track. (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 When the first version of RFC 4379 (a.k.a LSP Ping) were deployed it was quickly understood that in some inter autonomous system (AS) and inter-area deployments a LSR replying to an MPLS Echo request LSR may not have the available route to the initiator. The Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation. This document describes extensions to LSP Ping mechanism to enable LSRs to have the capability to relay the Echo Response by a set of routable intermediate nodes. This document updates RFC 4379. 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? Nothing out of the ordinary. 2015-07-09: Pulling a document back this late in the process is certainly "out of the ordinary". The updates to the draft were discussed at the working group meeting in Dallas, and an MPLS-RT review were done at about the same time and the wglc was done. The effect is that the document (now) has been very well reviewed and has good support in the working. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? 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? We know of implementations and deployments of this specification. We also have indications that vendors have plans to implement. , A poll for implementations has been sent to the working group, and the Shepherd Write-Up will be updated as we receive more information. 2015-07-09: We started a new implementation poll during the wglc, the result is about the same, but the "intention to implement" is slightly strong. Also one of the implementers stated that they were in the process of updating their implementation to match the specification as it stands after the update. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document Shepherd Deborah Brungard is the responsible AD (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 is convinced that the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, there has been a good debate on this draft, most of it taking place when the individual the preceded the working group document was reviewed by the MPLS review team. (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 such reviews are necessary. (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 such 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. All the authors has replied to the IPR poll, stating that they are not aware of any other IPR than what is already disclosed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure against this document. The terms quoted are such that it has not generated any discussion, we have accepted such terms for along term. (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? The LSP Ping is a very commonly deployed protocol, the extensions described/specified in this document has been identified as necessary by several operators and implementers. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Update to the Shepherds Writeup (for version -04) - marked Oct 2014. The ID nits points out that the pre-5378 boiler plate is used, however the shepherd does not think this is necessary, since both the original co-authors of RFC 4379 have granted the BCP78 rights to the IETF Trust. 2015-07-09: The discussion the pre-5378 boiler plate resulted in that the we to not use the the boiler-plate. There are no ad verbatim quotes from RFC 4379. The document itself is a merger of two individual drafts. The first is pre-5378, but both authors has announced that they are willing to assign there rights to the IETF trust. The other document is post-5378. Oct 2014: The statement above is not correct, it it true that we had the two original co-authors agree to grant their BCP 78 rights to the IANA trust, however after further investigation there are many more people that would need to do the same. We have done an effort to reach all of them, but did not succeed, so the pre-5378 boilet plate should be used in this document. Oct 2014 / 2015-07-09: The nits tool find one instance of non-RFC2606-compliant FQDNs in the document.. As far as the shepherd understands this is generated by one of the authors mail address. No other nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes - the references are correctly split up in normative and informative. (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 normative references are to existing RFCs. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (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. There are no RFCs for which the status is changed, but RFC 4379 is updated, this is discussed in the abstract and in the Introduction. (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 (and the info related to in the draft) is well and clearly written, a new message type is requested. The shepherd has reviewed the IANA section several times. (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. No such new registries. (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. Non such automated checks necessary. |
2015-07-09
|
10 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2015-07-06
|
10 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-10.txt |
2015-06-02
|
09 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG cleared. |
2015-06-02
|
09 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2015-05-25
|
09 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-09.txt |
2015-04-28
|
08 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-08.txt |
2015-03-25
|
07 | Amy Vezza | Shepherding AD changed to Deborah Brungard |
2015-03-07
|
07 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-07.txt |
2015-03-03
|
06 | Adrian Farrel | Revised I-D now needs to be run through full WG process before a new publication request is issued |
2014-12-18
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sean Turner. |
2014-12-12
|
06 | Adrian Farrel | Authors plan to revise I-D for readability |
2014-12-12
|
06 | Adrian Farrel | Tag Revised I-D Needed - Issue raised by WG set. |
2014-12-12
|
06 | Adrian Farrel | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2014-12-12
|
06 | Adrian Farrel | Returned to working group for more work at the request of the authors. |
2014-12-12
|
06 | Adrian Farrel | IESG state changed to AD is watching from Waiting for AD Go-Ahead::Point Raised - writeup needed |
2014-12-10
|
06 | Adrian Farrel | During the follow-up WG last call, two of the co-authors raised the issue of needing an English language editing pass. |
2014-12-05
|
06 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-06.txt |
2014-12-04
|
05 | Adrian Farrel | The plan is to check this revision with the people who raised the most substantive comments and then do a further working group last call |
2014-12-04
|
05 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for AD Go-Ahead::AD Followup |
2014-11-14
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-11-14
|
05 | Lizhong Jin | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-11-14
|
05 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-05.txt |
2014-10-13
|
04 | Adrian Farrel | Hi, Last call is over. You got a number of comments: Ops Dir review from Carlos. You're already discussing. IANA statement from Pearl. Needs a … Hi, Last call is over. You got a number of comments: Ops Dir review from Carlos. You're already discussing. IANA statement from Pearl. Needs a response. Gen Art review from Joel. Needs a response. I'll put the document into "Revised I-D needed" state. Thanks for the work. Adrian |
2014-10-13
|
04 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2014-10-13
|
04 | Loa Andersson | The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping … The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping draft-ietf-mpls-lsp-ping-relay-reply-03 is published as an RFC on the Standards Track. (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? We request that the document is published as a Proposed Standard. This document specifies protocol extensions to LSP Ping to enable a replying LSR to have the capability to relay Echo Response messages. Since the LSP Ping protocol is extended this is a Standards Track document. The document header says Standards Track. (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 When the first version of RFC 4379 (a.k.a LSP Ping) were deployed it was quickly understood that in some inter autonomous system (AS) and inter-area deployments a LSR replying to an MPLS Echo request LSR may not have the available route to the initiator. The Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation. This document describes extensions to LSP Ping mechanism to enable LSRs to have the capability to relay the Echo Response by a set of routable intermediate nodes. This document updates RFC 4379. 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? Nothing out of the ordinary. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? 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? We know of implementations and deployments of this specification. We also have indications that vendors have plans to implement. , A poll for implementations has been sent to the working group, and the Shepherd Write-Up will be updated as we receive more information. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document Shepherd Adrian Farrel is the responsible AD (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 is convinced that the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, there has been a good debate on this draft, most of it taking place when the individual the preceded the working group document was reviewed by the MPLS review team. (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 such reviews are necessary. (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 such 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. All the authors has replied to the IPR poll, stating that they are not aware of any other IPR than what is already disclosed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure against this document. The terms quoted are such that it has not generated any discussion, we have accepted such terms for along term. (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? The LSP Ping is a very commonly deployed protocol, the extensions described/specified in this document has been identified as necessary by several operators and implementers. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Update to the Shepherds Writeup (for version -04) - marked Oct 2014. The ID nits points out that the pre-5378 boiler plate is used, however the shepherd does not think this is necessary, since both the original co-authors of RFC 4379 have granted the BCP78 rights to the IETF Trust. Oct 2014: The statement above is not correct, it it true that we had the two original co-authors agree to grant their BCP 78 rights to the IANA trust, however after further investigation there are many more people that would need to do the same. We have done an effort to reach all of them, but did not succeed, so the pre-5378 boilet plate should be used in this document. Oct 2014: The nits tool finds a cae of using uppercase "SHOULD" in combination with lowercase "not", this was introduced between version -03 and -04. The authors have agreed to change this for the next version. Oct 2014: The nits toll also find a case of an unused reference, theis was also introduced between version -03 and -04, authors for a short period of time had text in the document making this reference necessary, but before posting agreed to not include that text. The authors have agreed to change this for the next version. Oct 2014: The nits tool find one instance of non-RFC2606-compliant FQDNs in the document.. A>s far as the shepherd understands this is generated by one of the authors mail address. No other nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes - the references are correctly split up in normative and informative. (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 normative references are to existing RFCs. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (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. There are no RFCs for which the status is changed, but RFC 4379 is updated, this is discussed in the abstract and in the Introduction. (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 (and the info related to in the draft) is well and clearly written, a new message type is requested. The shepherd has reviewed the IANA section several times. (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. No such new registries. (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. Non such automated checks necessary. |
2014-10-13
|
04 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-10-12
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Carlos Pignataro. |
2014-10-10
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-10-10
|
04 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-lsp-ping-relay-reply-04. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-lsp-ping-relay-reply-04. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has a comment regarding the IANA actions requested in this draft. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there are three actions which need to be completed. First, in the Message Types subregistry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registr located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a single new Message Type will be registered as follows: Value: [ TBD-at-registration ] Meaning: MPLS Relayed Echo Reply Reference: [ RFC-to-be ] IANA understands that the value to be registered will be allocated from the Standards Action range. Second, in the TLVs subregistry also in the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registr located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a new TLV is to be registered as follows: Type: [ TBD-at-registration ] TLV Name: Relay Node Address Stack TLV Reference: [ RFC-to-be ] Sub-TLV Registry: IANA understands that the value to be registered will be allocated from the Standards Action range. Third, in the Return Codes subregistry also in the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registr located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ a new Return Code to be registered as follows: Value: [ TBD ] Meaning: Response Packet length was exceeded unexpected by the Relay Node Address Stack TLV unexpected Reference: [ RFC-to-be ] IANA understands that the value to be registered will be allocated from the Standards Action range. NOTE: We see that although only one single "TBD" placeholder is used in all three requested types in the IANA considerations section of this draft, the authors are not requesting the *same* value for all three assignments, Message Type, TLV and Return Code. The single placeholder "TBD" indicates different values in different sections, 8.1, 8.2 and 8.3. IANA understands that these three actions are the only ones 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 only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2014-10-02
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2014-10-02
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2014-10-02
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2014-10-02
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2014-10-02
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2014-10-02
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2014-09-29
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-09-29
|
04 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Relayed Echo Reply mechanism for … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Relayed Echo Reply mechanism for LSP Ping) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Relayed Echo Reply mechanism for LSP Ping' 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 2014-10-13. 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 In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1945/ http://datatracker.ietf.org/ipr/828/ |
2014-09-29
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-09-29
|
04 | Amy Vezza | Last call announcement was changed |
2014-09-28
|
04 | Adrian Farrel | Last call was requested |
2014-09-28
|
04 | Adrian Farrel | Ballot approval text was generated |
2014-09-28
|
04 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2014-09-28
|
04 | Adrian Farrel | Last call announcement was changed |
2014-09-28
|
04 | Adrian Farrel | Last call announcement was generated |
2014-09-28
|
04 | Adrian Farrel | Ballot writeup was changed |
2014-09-28
|
04 | Adrian Farrel | Ballot writeup was changed |
2014-09-28
|
04 | Adrian Farrel | Ballot writeup was generated |
2014-08-27
|
04 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-08-04
|
04 | Loa Andersson | The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping … The MPLS WG requests that Relayed Echo Reply mechanism for LSP Ping draft-ietf-mpls-lsp-ping-relay-reply-03 is published as an RFC on the Standards Track. (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? We request that the document is published as a Proposed Standard. This document specifies protocol extensions to LSP Ping to enable a replying LSR to have the capability to relay Echo Response messages. Since the LSP Ping protocol is extended this is a Standards Track document. The document header says Standards Track. (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 When the first version of RFC 4379 (a.k.a LSP Ping) were deployed it was quickly understood that in some inter autonomous system (AS) and inter-area deployments a LSR replying to an MPLS Echo request LSR may not have the available route to the initiator. The Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation. This document describes extensions to LSP Ping mechanism to enable LSRs to have the capability to relay the Echo Response by a set of routable intermediate nodes. This document updates RFC 4379. 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? Nothing out of the ordinary. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? 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? We know of implementations and deployments of this specification. We also have indications that vendors have plans to implement. , A poll for implementations has been sent to the working group, and the Shepherd Write-Up will be updated as we receive more information. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document Shepherd Adrian Farrel is the responsible AD (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 is convinced that the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, there has been a good debate on this draft, most of it taking place when the individual the preceded the working group document was reviewed by the MPLS review team. (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 such reviews are necessary. (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 such 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. All the authors has replied to the IPR poll, stating that they are not aware of any other IPR than what is already disclosed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure against this document. The terms quoted are such that it has not generated any discussion, we have accepted such terms for along term. (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? The LSP Ping is a very commonly deployed protocol, the extensions described/specified in this document has been identified as necessary by several operators and implementers. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The ID nits points out that the pre-5378 boiler plate is used, however the shepherd does not think this is necessary, since both the original co-authors of RFC 4379 have granted the BCP78 rights to the IETF Trust. The document shepherd and (I think) the original authors of the RFC 4379 need advice on how to exactly handle this. No other nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes - the references are correctly split up in normative and informative. (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 normative references are to existing RFCs. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (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. There are no RFCs for which the status is changed, but RFC 4379 is updated, this is discussed in the abstract and in the Introduction. (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 (and the info related to in the draft) is well and clearly written, a new message type is requested. The shepherd has reviewed the IANA section several times. (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. No such new registries. (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. Non such automated checks necessary. |
2014-08-04
|
04 | Loa Andersson | State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org |
2014-08-04
|
04 | Loa Andersson | Responsible AD changed to Adrian Farrel |
2014-08-04
|
04 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2014-08-04
|
04 | Loa Andersson | IESG state changed to Publication Requested |
2014-08-04
|
04 | Loa Andersson | IESG process started in state Publication Requested |
2014-08-04
|
04 | Loa Andersson | Changed document writeup |
2014-08-02
|
04 | Loa Andersson | Waiting for review of the shepherds write-up |
2014-08-02
|
04 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2014-07-30
|
04 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-04.txt |
2014-07-21
|
03 | Martin Vigoureux | tag was wrong. Revised I-D Needed - Issue raised by WGLC instead of Revised I-D Needed - Issue raised by WG |
2014-07-21
|
03 | Martin Vigoureux | Tag Revised I-D Needed - Issue raised by WGLC set. Tag Revised I-D Needed - Issue raised by WG cleared. |
2014-06-16
|
03 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG set. |
2014-06-16
|
03 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-05-22
|
03 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Consensus: Waiting for Write-Up |
2014-05-21
|
03 | Loa Andersson | Changed document writeup |
2014-05-21
|
03 | Loa Andersson | Changed document writeup |
2014-05-18
|
03 | Loa Andersson | Changed document writeup |
2014-05-16
|
03 | Loa Andersson | Changed document writeup |
2014-05-16
|
03 | Loa Andersson | Tag Other - see Comment Log cleared. |
2014-05-16
|
03 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2014-05-15
|
03 | Loa Andersson | Wait for one response on the IPR poll |
2014-05-15
|
03 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document |
2014-04-17
|
03 | Loa Andersson | IPR Poll |
2014-04-17
|
03 | Loa Andersson | Tag Other - see Comment Log set. |
2014-04-02
|
03 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-03.txt |
2014-03-17
|
02 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2014-03-17
|
02 | Loa Andersson | Document shepherd changed to Loa Andersson |
2014-02-14
|
02 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-02.txt |
2013-08-05
|
01 | Lizhong Jin | New version available: draft-ietf-mpls-lsp-ping-relay-reply-01.txt |
2013-03-10
|
00 | Zhi Zheng | New version available: draft-ietf-mpls-lsp-ping-relay-reply-00.txt |