OSPFv3 Code Point for MPLS LSP Ping
draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
06 | Gunter Van de Velde | Request closed, assignment withdrawn: Tianran Zhou Last Call OPSDIR review |
2024-01-26
|
06 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-04-11
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-03-14
|
06 | (System) | RFC Editor state changed to AUTH48 |
2022-02-04
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2022-02-04
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-02-04
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-02-04
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-03
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-03
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-03
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-02
|
06 | (System) | RFC Editor state changed to IANA from EDIT |
2022-01-31
|
06 | (System) | RFC Editor state changed to EDIT |
2022-01-31
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-01-31
|
06 | (System) | Announcement was received by RFC Editor |
2022-01-31
|
06 | (System) | IANA Action state changed to In Progress |
2022-01-31
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-01-31
|
06 | Cindy Morgan | IESG has approved the document |
2022-01-31
|
06 | Cindy Morgan | Closed "Approve" ballot |
2022-01-31
|
06 | Cindy Morgan | Ballot approval text was generated |
2022-01-31
|
06 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-12-02
|
06 | (System) | Removed all action holders (IESG state changed) |
2021-12-02
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2021-12-02
|
06 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-12-01
|
06 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-11-30
|
06 | Roman Danyliw | [Ballot comment] Thank you to Tero Kivinen for the SECDIR review. |
2021-11-30
|
06 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-11-29
|
06 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-11-29
|
06 | John Scudder | [Ballot comment] Much like Rob Wilton, I suggest renaming code point 1 from “OSPF” to “OSPFv2” as part of this effort. |
2021-11-29
|
06 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-11-29
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-11-29
|
06 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-11-29
|
06 | Lars Eggert | [Ballot comment] The IANA review of this document seems to not have concluded yet. Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) … [Ballot comment] The IANA review of this document seems to not have concluded yet. Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/zayJNOhwH1aA53cmY44IINORV-I). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml |
2021-11-29
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-11-28
|
06 | Robert Wilton | [Ballot comment] Thank you for this short document. Only one minor question regarding how the existing OSPF code points are being changed. I presume that … [Ballot comment] Thank you for this short document. Only one minor question regarding how the existing OSPF code points are being changed. I presume that it has been discussed and there is a good reason as to why the existing OSPF code point is not being relabeled as OSFPv2 to avoid long term confusion? Rob |
2021-11-28
|
06 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-11-27
|
06 | Benjamin Kaduk | [Ballot comment] Section 4 When the protocol field in the received Segment ID sub-TLV Type 35 and Type 36 is OSPF (value 1), … [Ballot comment] Section 4 When the protocol field in the received Segment ID sub-TLV Type 35 and Type 36 is OSPF (value 1), the responder MAY treat the protocol value as "Any IGP Protocol" (value 0) according to step 4a of Section 7.4 of [RFC8287]. This allows the responder to support legacy implementations that use value 1 to indicate OSPFv3. Is there any guidance to give on how long we expect there to be need for the "treat as any" behavior to be implemented? ("No" is a valid answer.) Section 6 This document updates [RFC8287], by specifying that the "OSPF" code points SHOULD be used only for OSPFv2. Why do we use SHOULD here but say in §4 that the initiator "MUST NOT set [...] as OSPF (value 1)"? Section 7 I have a mild preference for noting in the I-D when an early allocation is being confirmed, but since it doesn't end up in the final RFC it probably doesn't really matter. Section 8 Pedantically, this document does encourage you ("MAY") to treat the OSPV(v2) codepoint as "any protocol" in a couple of scenarios, which would in principle open up a risk of an attacker causing you to use (e.g.) IS-IS when OSPF was intended. Is that a significant new risk? Probably not. But it may be enough to move away from saying "does not introduce any additional security considerations". "no significant new security considerations" would be unobjectionable to me. NITS Section 6 the Protocol field of the Segment ID sub-TLV. Section 6 of [RFC8287] defines the code point for OSPF to be used in the Protocol field of the DDMAP TLV. I'd suggest expanding "DDMAP" here. |
2021-11-27
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-11-25
|
06 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Tero Kivinen. Sent review to list. |
2021-11-25
|
06 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tero Kivinen |
2021-11-25
|
06 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tero Kivinen |
2021-11-22
|
06 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-11-22
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-11-18
|
06 | Cindy Morgan | Placed on agenda for telechat - 2021-12-02 |
2021-11-18
|
06 | Martin Vigoureux | Ballot has been issued |
2021-11-18
|
06 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2021-11-18
|
06 | Martin Vigoureux | Created "Approve" ballot |
2021-11-18
|
06 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-11-18
|
06 | Martin Vigoureux | Ballot writeup was changed |
2021-11-18
|
06 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-11-18
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-11-18
|
06 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06.txt |
2021-11-18
|
06 | (System) | New version accepted (logged-in submitter: Nagendra Nainar) |
2021-11-18
|
06 | Nagendra Nainar | Uploaded new revision |
2021-11-02
|
05 | (System) | Changed action holders to Mustapha Aissaoui, Carlos Pignataro, Martin Vigoureux, Nagendra Nainar (IESG state changed) |
2021-11-02
|
05 | Martin Vigoureux | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup |
2021-09-23
|
05 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-09-23
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-09-23
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-09-23
|
05 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-05.txt |
2021-09-23
|
05 | (System) | New version approved |
2021-09-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: Carlos Pignataro , Mustapha Aissaoui , Nagendra Nainar |
2021-09-23
|
05 | Nagendra Nainar | Uploaded new revision |
2021-06-24
|
04 | (System) | Changed action holders to Mustapha Aissaoui, Carlos Pignataro, Martin Vigoureux, Nagendra Nainar (IESG state changed) |
2021-06-24
|
04 | Martin Vigoureux | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
2021-06-22
|
04 | Matthew Bocci | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Matthew Bocci. Sent review to list. |
2021-06-21
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-06-18
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-06-18
|
04 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mpls-lsp-ping-ospfv3-codepoint-04. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mpls-lsp-ping-ospfv3-codepoint-04. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Protocol in the Segment ID sub-TLV registry on the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry page located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ the existing registration for: Value: 3 Meaning: OSPFv3 Reference: [ RFC-to-be ] will have its reference changed to [ RFC-to-be ]. In addition, the note to value 1 will be changed to: "To be used for OSPFv2 only" Second, in the Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV registry on the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry page located at: https://www.iana.org/assignments/mpls-lsp-ping-parameters/ the existing registration for: Value: 7 Meaning: OSPFv3 Reference: [ RFC-to-be ] will have its reference changed to [ RFC-to-be ]. In addition, the note to value 5 will be changed to: "To be used for OSPFv2 only" The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2021-06-11
|
04 | Christer Holmberg | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. Sent review to list. |
2021-06-10
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-06-10
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-06-10
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tero Kivinen. Sent review to list. |
2021-06-10
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2021-06-10
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2021-06-08
|
04 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Matthew Bocci |
2021-06-08
|
04 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Matthew Bocci |
2021-06-08
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2021-06-08
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tianran Zhou |
2021-06-07
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-06-07
|
04 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-06-21): From: The IESG To: IETF-Announce CC: Loa Andersson , draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org, loa@pi.nu, martin.vigoureux@nokia.com, … The following Last Call announcement was sent out (ends 2021-06-21): From: The IESG To: IETF-Announce CC: Loa Andersson , draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org, loa@pi.nu, martin.vigoureux@nokia.com, mpls-chairs@ietf.org, mpls@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (OSPFv3 CodePoint for MPLS LSP Ping) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'OSPFv3 CodePoint for MPLS 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 last-call@ietf.org mailing lists by 2021-06-21. 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 IANA has created "Protocol in the Segment IS Sub-TLV" and "Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV" registries under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC8287 defines the code points for OSPF and IS-IS. This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID SUb-TLV indicates the use of IPv6. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ospfv3-codepoint/ No IPR declarations have been submitted directly on this I-D. |
2021-06-07
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-06-07
|
04 | Martin Vigoureux | Requested Early review by RTGDIR |
2021-06-07
|
04 | Martin Vigoureux | Last call was requested |
2021-06-07
|
04 | Martin Vigoureux | Ballot approval text was generated |
2021-06-07
|
04 | Martin Vigoureux | Ballot writeup was generated |
2021-06-07
|
04 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2021-06-07
|
04 | Martin Vigoureux | Last call announcement was generated |
2021-06-07
|
04 | Martin Vigoureux | Intended Status changed to Proposed Standard from None |
2021-06-07
|
04 | Martin Vigoureux | Last call announcement was generated |
2021-06-07
|
04 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-06-07
|
04 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2021-03-26
|
04 | Loa Andersson | The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint Is … The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint 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? This document should be published an RFC on the Standards Track. The document header says Standard Track. This document makes necessary adjustments and extensions to registries where the registration Procedures are Standards Action. (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: This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID SUb-TLV indicates the use of IPv6. Working Group Summary: The progress of this document was smooth and it is generally understood within the working group that the document is needed. Document Quality: There are existing implementations of the protocol, using the early allocations. Personnel: Loa Andersson is the Document Shepherd. Martin Vigoureux is the Responsible Area Director . Note: Deborah Brungard was the responsible AD at the time of the early allocation of code points for this document. (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/Working Group Chair was part of the discussion that lead to the decision to write this document and the Shepherd has closely followed every step until the document is now ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns! The document has been reviewed by all the key people. (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 review 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? The authors (no contributors listed) have all confirmed that they are unaware of any IPR that relates 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. There are no IPR disclosures against 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? The working group support this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summaries 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 document passes the Nits-tool clean, no other nits identified. Nits tool point to a reference to the LSP Ping IANA register and ask if that is a down ref (see below). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? There are no informative references. But this is a correct treatment of the 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 the references are to existing standard track RFCs and to BCP 14. (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 down-ref's! Nits tool point to a reference to the LSP Ping IANA register and ask if that is a non IETF document and a down-ref. The document is of the opinion that that this can't be construed as a down-ref. (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. This document updates RFC 8287, this is listed in the header and discussed in the Abstract and 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 8126). This document is about codepoints and interpretation of codepoints, so reviewing the document is implicitly reviewing the IANA section. However, there is also a well-written IANA section. the Shepherd has been involved in and agreed to any changes in the IANA section. The IANA registries from which the new codepoints are allocated (early allocation) are clearly identified. (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 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, YANG modules, etc. No such reviews performed. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? This is not a YANG model |
2021-03-26
|
04 | Loa Andersson | Responsible AD changed to Martin Vigoureux |
2021-03-26
|
04 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-03-26
|
04 | Loa Andersson | IESG state changed to Publication Requested from I-D Exists |
2021-03-26
|
04 | Loa Andersson | IESG process started in state Publication Requested |
2021-03-26
|
04 | Loa Andersson | Changed consensus to Yes from Unknown |
2021-03-26
|
04 | Loa Andersson | The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint Is … The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint 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? This document should be published an RFC on the Standards Track. The document header says Standard Track. This document makes necessary adjustments and extensions to registries where the registration Procedures are Standards Action. (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: This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID SUb-TLV indicates the use of IPv6. Working Group Summary: The progress of this document was smooth and it is generally understood within the working group that the document is needed. Document Quality: There are existing implementations of the protocol, using the early allocations. Personnel: Loa Andersson is the Document Shepherd. Martin Vigoureux is the Responsible Area Director . Note: Deborah Brungard was the responsible AD at the time of the early allocation of code points for this document. (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/Working Group Chair was part of the discussion that lead to the decision to write this document and the Shepherd has closely followed every step until the document is now ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns! The document has been reviewed by all the key people. (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 review 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? The authors (no contributors listed) have all confirmed that they are unaware of any IPR that relates 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. There are no IPR disclosures against 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? The working group support this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summaries 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 document passes the Nits-tool clean, no other nits identified. Nits tool point to a reference to the LSP Ping IANA register and ask if that is a down ref (see below). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? There are no informative references. But this is a correct treatment of the 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 the references are to existing standard track RFCs and to BCP 14. (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 down-ref's! Nits tool point to a reference to the LSP Ping IANA register and ask if that is a non IETF document and a down-ref. The document is of the opinion that that this can't be construed as a down-ref. (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. This document updates RFC 8287, this is listed in the header and discussed in the Abstract and 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 8126). This document is about codepoints and interpretation of codepoints, so reviewing the document is implicitly reviewing the IANA section. However, there is also a well-written IANA section. the Shepherd has been involved in and agreed to any changes in the IANA section. The IANA registries from which the new codepoints are allocated (early allocation) are clearly identified. (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 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, YANG modules, etc. No such reviews performed. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? This is not a YANG model |
2021-03-20
|
04 | Loa Andersson | The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint Is … The MPLS Working Group request that OSPFv3 CodePoint for MPLS LSP Ping draft-ietf-mpls-lsp-ping-ospfv3-codepoint 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? This document should be published an RFC on the Standards Track (Proposed Standard). The ducument header says Standard TRack. This document makes necesary adjustments and extensins to registries where the registration Procedures are Srandars Action. (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: This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID SUb-TLV indicates the use of IPv6. Working Group Summary: The progress of this document was smooth and it is generally understood within the working group that the document is needed. Document Quality: There are existing implementations of the protocol, using the early allocations. Personnel: Loa Andersson is the Document Shepherd. Martin Vigoureux is the Responsible Area Director . Note: Deborah Brungard was the responsible AD at the time of the early allocation of code points for this document. (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/Working Group Chair was part of the disccussion that lead to the decission to write this document and the Shepherd has closely followed every step until the document is now ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns! The document has been reviewed by all the key people. (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 review 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? The authors (no contributors listed) have all confirmed that they are unaware of any IPR that relates 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. There are no IPR disclosures against 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? The working group support this document. (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 document passes the Nits-tool clean, no other nits identified. Nits tool point to a reference to the LSP Ping IANA register and ask if that is a down ref (see below). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal reviews necessary. (13) Have all references within this document been identified as either normative or informative? There are no informative references. But this is a correct treatment of the 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 the references are to existing standard track RFCs and to BCP 14. (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 down-ref's! Nits tool point to a reference to the LSP Ping IANA register and ask if that is a non IETF document and a down-ref. The document is of the opinion that that this can't be construed as a down-ref. (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. This document updates RFC 8287, this is listed in the header and discussed in the Abstract and 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 8126). This document is about codepoints and interpretation of codepoints, so reviewing the document is implicitly reviewing the IANA section. However, there is also a well-written IANA section. the Shepherd has been involded in and agreed to any changes in the IANA section. The IANA registries from which the new codepoints are allocated (early allocation) are clearly identified. (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 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, YANG modules, etc. No such reviews performed. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? This is not a YANG model |
2021-03-19
|
04 | Loa Andersson | Notification list changed to Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org from Loa Andersson <loa@pi.nu> |
2021-03-19
|
04 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2021-01-27
|
04 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-04.txt |
2021-01-27
|
04 | (System) | New version accepted (logged-in submitter: Nagendra Nainar) |
2021-01-27
|
04 | Nagendra Nainar | Uploaded new revision |
2021-01-18
|
03 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2021-01-18
|
03 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2020-11-27
|
03 | Loa Andersson | IPR poll started |
2020-11-20
|
03 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-03.txt |
2020-11-20
|
03 | (System) | New version approved |
2020-11-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: Mustapha Aissaoui , Nagendra Nainar , Carlos Pignataro |
2020-11-20
|
03 | Nagendra Nainar | Uploaded new revision |
2020-11-16
|
02 | (System) | Document has expired |
2020-05-07
|
02 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-02.txt |
2020-05-07
|
02 | (System) | New version approved |
2020-05-07
|
02 | (System) | Request for posting confirmation emailed to previous authors: Mustapha Aissaoui , Nagendra Kumar , Carlos Pignataro |
2020-05-07
|
02 | Nagendra Nainar | Uploaded new revision |
2020-05-06
|
01 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-01.txt |
2020-05-06
|
01 | (System) | New version approved |
2020-05-06
|
01 | (System) | Request for posting confirmation emailed to previous authors: Mustapha Aissaoui , Carlos Pignataro , Nagendra Kumar |
2020-05-06
|
01 | Nagendra Nainar | Uploaded new revision |
2020-04-18
|
00 | Loa Andersson | Notification list changed to Loa Andersson <loa@pi.nu> |
2020-04-18
|
00 | Loa Andersson | Document shepherd changed to Loa Andersson |
2020-03-24
|
00 | Loa Andersson | This document now replaces draft-nainar-mpls-lsp-ping-ospfv3-codepoint instead of None |
2020-03-24
|
00 | Nagendra Nainar | New version available: draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt |
2020-03-24
|
00 | (System) | WG -00 approved |
2020-03-23
|
00 | Nagendra Nainar | Set submitter to "Nagendra Kumar Nainar ", replaces to draft-nainar-mpls-lsp-ping-ospfv3-codepoint and sent approval email to group chairs: mpls-chairs@ietf.org |
2020-03-23
|
00 | Nagendra Nainar | Uploaded new revision |