Residence Time Measurement in MPLS Networks
draft-ietf-mpls-residence-time-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-31
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-05-12
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-04-27
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-04-10
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2017-04-07
|
15 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-04-03
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-04-03
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2017-04-03
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2017-03-31
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-03-30
|
15 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2017-03-20
|
15 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2017-03-20
|
15 | (System) | IANA Action state changed to In Progress |
2017-03-20
|
15 | (System) | RFC Editor state changed to EDIT |
2017-03-20
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-03-20
|
15 | (System) | Announcement was received by RFC Editor |
2017-03-17
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2017-03-17
|
15 | Cindy Morgan | IESG has approved the document |
2017-03-17
|
15 | Cindy Morgan | Closed "Approve" ballot |
2017-03-17
|
15 | Cindy Morgan | Ballot writeup was changed |
2017-03-17
|
15 | Deborah Brungard | Ballot approval text was changed |
2017-03-07
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-03-07
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-03-07
|
15 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-15.txt |
2017-03-07
|
15 | (System) | New version approved |
2017-03-07
|
15 | (System) | Request for posting confirmation emailed to previous authors: Stefano Ruffini , Gregory Mirsky , Sasha Vainshtein , mpls-chairs@ietf.org, John Drake , Stewart Bryant , … Request for posting confirmation emailed to previous authors: Stefano Ruffini , Gregory Mirsky , Sasha Vainshtein , mpls-chairs@ietf.org, John Drake , Stewart Bryant , Eric Gray |
2017-03-07
|
15 | Greg Mirsky | Uploaded new revision |
2017-03-02
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-03-02
|
14 | Alia Atlas | [Ballot comment] Thank you for the planned text to update the document to address my Discuss & comment. |
2017-03-02
|
14 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from Discuss |
2017-03-02
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-03-01
|
14 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-03-01
|
14 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-03-01
|
14 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-03-01
|
14 | Ben Campbell | [Ballot comment] I have no objection, but do have some a few minor comments: Substantive: -2.1, 4th paragraph from end: Can you offer guidance on … [Ballot comment] I have no objection, but do have some a few minor comments: Substantive: -2.1, 4th paragraph from end: Can you offer guidance on what might constitute a reasonably bound wait time?\ -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same message? Editorial: - Abstract: The last paragraph is a single, long sentence. Please consider breaking it into simpler sentences. - 2.1, paragraph 9: "This bit, once it is set by a two- step mode device, MUST stay set accordingly": Can that MUST be stated in process terms? That is, MUST NOT unset this bit..." -2.1, paragraph 11: "Without loss of generality should note that handling of Sync event messages..." : I don't follow the sentence; are words missing and/or out of order? -- "Following outlines handling of PTP Sync event message by the two-step RTM node.": I think there's a missing "the" at the start. It's absence completely changes the meaning of "following outlines"-- as written it seem like the verb is "following", but I think you mean it to be "outlines". -- I have trouble matching some pronouns to their antecedents in the rest of the paragraph. |
2017-03-01
|
14 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-03-01
|
14 | Alia Atlas | [Ballot discuss] Thank you for a clear document. I think that this should be a straightforward Discuss to better clarify. In Section 4.8.1, it says … [Ballot discuss] Thank you for a clear document. I think that this should be a straightforward Discuss to better clarify. In Section 4.8.1, it says "The RTM Set sub-object contains an ordered list, from egress node to ingress node, of the RTM capable nodes along the LSP's path." but the sub-TLVs (as most clearly indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant to be a list of interfaces. It isn't clear whether these are supposed to be the egress interface, the ingress interface, or just any interface - or why sending just a Router ID wouldn't be sufficient. There is no indication as to whether it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one to use. |
2017-03-01
|
14 | Alia Atlas | [Ballot comment] 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA isn't defined. While I understand that a normative reference isn't … [Ballot comment] 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA isn't defined. While I understand that a normative reference isn't desirable - instead of "left for future study", it would be better to say that the sub-TLV should use the same format as in Sec 4.3 and that the type allocation and full details are left to a future document. This is exactly how gaps are created for networks running only IPv6. If draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations and had a clear time-frame for how and when to progress, this would also be a Discuss. |
2017-03-01
|
14 | Alia Atlas | [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas |
2017-03-01
|
14 | Benjamin Kaduk | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Benjamin Kaduk. |
2017-03-01
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-03-01
|
14 | Kathleen Moriarty | [Ballot comment] I agree with Stephen after reading though Ben's excellent review and the responses. Thanks for incorporating his suggestions. |
2017-03-01
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-03-01
|
14 | Mirja Kühlewind | [Ballot comment] High level comment: Maybe extend the security section a bit and describe what can happen in the worse case if the value has … [Ballot comment] High level comment: Maybe extend the security section a bit and describe what can happen in the worse case if the value has been modified to a too high or too low value; and maybe even given some guidance on performing additional checks to figure out if a given value is reasonable for a given path or not. Questions: - Can you explain why PTPType, Port ID, and Sequence ID are needed in the PTP Sub-TLV format if those values are already in the PTP packet itself that follows? - Why is it necessary to define PTP sub-TLV (and have a registry for one value only)? Are you expecting to see more values here? What would those values be? - Similar to Spencer's question: Why don't you also define a Sub-TLV format for NTP? - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with values defined as follows: * 0b001..." Maybe I don't understand what a bit-map field is here but these are more then 3 bits...? - also sec 4.3.: "Value contains variable number of bit-map fields so that overall number of bits in the fields equals Length * 8." However there is no field 'Value' in the figure... Also the following explanation about future bit-maps is really confusing to me; why don't you just say that the rest as indicated by the length field must be padded with zeros...? - Should section 4.8 maybe be a subsection of 4.7? This part confused me a bit because the example seems to be generic but the rest is RSVP-TE specific, right? Maybe move the example as a separate section before or after the whole section 4...? Nits: - Maybe change to title to: Residence Time Measurement (RTM) in MPLS network - There are (still) some not spelled out abbreviations (LDP, PW); in turn others are extended twice (e.g. PTP)... - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also indicate it as optional in the figure: Sub-TLV (optional) |
2017-03-01
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-03-01
|
14 | Stephen Farrell | [Ballot comment] Ben Kaduk's fine secdir review [1] and the resulting discussion with authors made me very confident that this one only needed a cursory … [Ballot comment] Ben Kaduk's fine secdir review [1] and the resulting discussion with authors made me very confident that this one only needed a cursory read from me. Thanks to all for that! [1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=KaiVCjdJVovCj049ksWXoot6B98 |
2017-03-01
|
14 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-02-28
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-02-27
|
14 | Robert Sparks | Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2017-02-26
|
14 | Spencer Dawkins | [Ballot comment] I'm a bit confused on one point. There's one reference to NTP in the Introduction, everything else is about PTP, but the specification … [Ballot comment] I'm a bit confused on one point. There's one reference to NTP in the Introduction, everything else is about PTP, but the specification never actually says if this mechanism is intended to be usable for NTP as well. Could that be clearer? |
2017-02-26
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-02-23
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2017-02-23
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2017-02-22
|
14 | Deborah Brungard | Changed consensus to Yes from Unknown |
2017-02-22
|
14 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-02-22
|
14 | Deborah Brungard | Ballot has been issued |
2017-02-22
|
14 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-02-22
|
14 | Deborah Brungard | Created "Approve" ballot |
2017-02-22
|
14 | Deborah Brungard | Ballot writeup was changed |
2017-02-22
|
14 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-14.txt |
2017-02-22
|
14 | (System) | New version approved |
2017-02-22
|
14 | (System) | Request for posting confirmation emailed to previous authors: Stefano Ruffini , Gregory Mirsky , Sasha Vainshtein , mpls-chairs@ietf.org, John Drake , Stewart Bryant , … Request for posting confirmation emailed to previous authors: Stefano Ruffini , Gregory Mirsky , Sasha Vainshtein , mpls-chairs@ietf.org, John Drake , Stewart Bryant , Eric Gray |
2017-02-22
|
14 | Greg Mirsky | Uploaded new revision |
2017-02-13
|
13 | Robert Sparks | Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2017-02-02
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2017-02-02
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2017-02-02
|
13 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Benjamin Kaduk |
2017-02-02
|
13 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Benjamin Kaduk |
2017-02-01
|
13 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'Team Will not Review Version' |
2017-02-01
|
13 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2017-02-01
|
13 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2017-01-31
|
13 | Deborah Brungard | Telechat date has been changed to 2017-03-02 from 2017-02-16 |
2017-01-30
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-01-30
|
13 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-13.txt |
2017-01-30
|
13 | (System) | New version approved |
2017-01-30
|
13 | (System) | Request for posting confirmation emailed to previous authors: "John Drake" , mpls-chairs@ietf.org, "Stefano Ruffini" , "Gregory Mirsky" , "Stewart Bryant" , "Sasha Vainshtein" , … Request for posting confirmation emailed to previous authors: "John Drake" , mpls-chairs@ietf.org, "Stefano Ruffini" , "Gregory Mirsky" , "Stewart Bryant" , "Sasha Vainshtein" , "Eric Gray" |
2017-01-30
|
13 | Greg Mirsky | Uploaded new revision |
2017-01-24
|
12 | Deborah Brungard | Telechat date has been changed to 2017-02-16 from 2017-02-02 |
2017-01-18
|
12 | Benjamin Kaduk | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Benjamin Kaduk. |
2017-01-17
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-01-13
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-01-13
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mpls-residence-time-12.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mpls-residence-time-12.txt. If any part of this review is inaccurate, please let us know. We have a question about one of the actions requested in the IANA Considerations section of [ RFC-to-be ]. The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are nine actions which we must complete. First, in the MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types) subregistry of the Generic Associated Channel (G-ACh) Parameters registry located at: https://www.iana.org/assignments/g-ach-parameters/ a single new G-ACh will be registered as follows: Value: [ TBD-at-registration ] Description: Residence Time Measurement Reference: [ RFC-to-be ] Second, a new registry is to be created called the MPLS RTM TLV Registry. This registry will be a subregistry of the Generic Associated Channel (G-ACh) Parameters registry located at: https://www.iana.org/assignments/g-ach-parameters/ Values from 0 through 127 shall be managed via IETF Review as defined in RFC 5226. Values 128 through 191 will be managed via First Come, First Served as defined in RFC 5226. Values 192 through 254 are for Private Use as defined in RFC 5226. Value 255 is reserved. There are initial values in the new registry as follows: +-----------+-------------------------------+---------------+ | Value | Description | Reference | +-----------+-------------------------------+---------------+ | 0 | Reserved | [ RFC-to-be ] | | 1 | No payload | [ RFC-to-be ] | | 2 | PTPv2, Ethernet encapsulation | [ RFC-to-be ] | | 3 | PTPv2, IPv4 Encapsulation | [ RFC-to-be ] | | 4 | PTPv2, IPv6 Encapsulation | [ RFC-to-be ] | | 5 | NTP | [ RFC-to-be ] | | 6-127 | Unassigned | | | 128 - 191 | Unassigned | | | 192 - 254 | Private Use | [ RFC-to-be ] | | 255 | Reserved | [ RFC-to-be ] | +-----------+-------------------------------+---------------+ Third, a new registry is to be created called the MPLS RTM Sub-TLV Registry. This registry will be a subregistry of the Generic Associated Channel (G-ACh) Parameters registry located at: https://www.iana.org/assignments/g-ach-parameters/ Values from 0 through 127 shall be managed via IETF Review as defined in RFC 5226. Values 128 through 191 will be managed via First Come, First Served as defined in RFC 5226. Values 192 through 254 are for Private Use as defined in RFC 5226. Value 255 is reserved. There are initial values in the new registry as follows: +-----------+-------------+---------------+ | Value | Description | Reference | +-----------+-------------+---------------+ | 0 | Reserved | [ RFC-to-be ] | | 1 | PTP | [ RFC-to-be ] | | 2-127 | Unassigned | | | 128 - 191 | Unassigned | | | 192 - 254 | Private Use | [ RFC-to-be ] | | 255 | Reserved | [ RFC-to-be ] | +-----------+-------------+---------------+ Fourth, in the OSPFv2 Extended Link TLV Sub-TLVs subregistry of the Open Shortest Path First v2 (OSPFv2) Parameters registry located at: https://www.iana.org/assignments/ospfv2-parameters/ a new Sub-TLV will be registered as follows: Value: [ TBD-at-Registration ] Description: RTM Capability Reference: [ RFC-to-be ] Fifth, in the Application Identifiers for TLV 251 subregistry of the IS-IS TLV Codepoints registry located at: https://www.iana.org/assignments/isis-tlv-codepoints/ a new registration will be made as follows: ID Value: [ TBD-at-Registration ] Description: RTM Allowed in Instance zero (y/n) Reference: [ RFC-to-be ] IANA Services Operator Question --> What should the value for "Allowed in Instance zero" be for this registration? Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Sixth, in the Attributes TLV Space subregistry of the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at: https://www.iana.org/assignments/rsvp-te-parameters/ a new registration will be made as follows: Type: [ TBD-at-Registration ] Name: RTM_SET sub-object Allowed on LSP_ATTRIBUTES: Yes Allowed on LSP_REQUIRED_ATTRIBUTES: No Allowed on LSP Hop Attributes: No Reference: [ RFC-to-be ] Seventh, a new registry is to be created called the Sub-TLV types of RTM_SET Sub-object registry. This new registry will be a subregistry of the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at: https://www.iana.org/assignments/rsvp-te-parameters/ Values from 0 through 127 shall be managed via IETF Review as defined in RFC 5226. Values 128 through 191 will be managed via First Come, First Served as defined in RFC 5226. Values 192 through 254 are for Private Use as defined in RFC 5226. Value 255 is reserved. There are initial values in the new registry as follows: +-----------+----------------------+---------------+ | Value | Description | Reference | +-----------+----------------------+---------------+ | 0 | Reserved | [ RFC-to-be ] | | 1 | IPv4 address | [ RFC-to-be ] | | 2 | IPv6 address | [ RFC-to-be ] | | 3 | Unnumbered interface | [ RFC-to-be ] | | 4-127 | Unassigned | | | 128 - 191 | Unassigned | | | 192 - 254 | Private Use | [ RFC-to-be ] | | 255 | Reserved | [ RFC-to-be ] | +-----------+----------------------+---------------+ Eighth, in the Attribute Flags subregistry of the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at: https://www.iana.org/assignments/rsvp-te-parameters/ a new Flag will be registered as follows: Bit No: [ TBD-at-Registration Name: RTM_SET Attribute Flags Path: Yes Attribute Flags Resv: Yes RRO: No ERO: No Reference: [ RFC-to-be ] Ninth, in the Error Codes and Globally-Defined Error Value Sub-Codes subregistry of the Resource Reservation Protocol (RSVP) Parameters located at: https://www.iana.org/assignments/rsvp-parameters/ three new values will be registered as follows: Error Code: [ TBD-at-Registration ] Meaning: Duplicate TLV Reference: [ RFC-to-be ] Error Code: [ TBD-at-Registration ] Meaning: Duplicate sub-TLV Reference: [ RFC-to-be ] Error Code: [ TBD-at-Registration ] Meaning: RTM_SET TLV Absent Reference: [ RFC-to-be ] The IANA Services Operator understands that these nine actions are the only ones required to be completed upon approval of [ 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. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-01-13
|
12 | Jürgen Schönwälder | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list. |
2017-01-11
|
12 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list. |
2017-01-10
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2017-01-10
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2017-01-09
|
12 | Loa Andersson | The MPLS working group requests that Residence Time Measurement in MPLS network … The MPLS working group requests that Residence Time Measurement in MPLS network draft-ietf-mpls-residence-time 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? The intended type of RFC is Proposed Standard. The document specifies protocol and protocol information elements, so Proposed Standard is the proper type of RFC. The documet 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 Thie document specifies a G-ACh based Residence Time Measurement capability and how it can be used by time synchronization protocols being transported over an MPLS domain. The Associated Channel was first specified in MPLS PW context, was generalized during the MPLS-TP project and is now frequently used across the entire MPLS technology. "Residence time" is the variable part of propagation delay when timing and synchronization messages are propagated along a path in the network. Knowing what this part of the delay is for each message makes it possible to more accurately determine the delay value to be included in e.g. a Precision Time Protocol (PTP) event message. Working Group Summary The working group processing of this group was fairly smooth, though some experts in the area have ben chiming in and very much improved the document. There has been a high degree of collaboration between members of the MPLS, TICTOC and BMWG Working Groups. There are currently 6 co- authors listed on the front page. We this was discussed (chairs, shepherd, AD and authors), we said that considering the level of contribution from different sources we agreed that it is motivated to have all 6 authors listed on the front page. Document Quality There has been no formal expert review. We are aware of intentions to implement this specification, an Implementation Poll has been started and the Write-Up will be as new information is available. Personnel Loa Andersson is the Document Shepherd. Deborah Brungard is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. In the MPLS working group the shepherd is appointed well before the working group adoption poll. The shepherd makes sure that the document is ready for the adoption poll (including detailed review and IPR poll). The shepherd follows the document closely and review the when necessary, particular interest is given to the IANA section and IPR disclosures. This particular was reviewed by the shepherd before the WG adoption poll, during the WG process and prior to the WGLC, the shepherd has also closely followed the updates to the document that were caused by these reviews. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No such reviews necessary, though we made sure that synchronization experts has reviewed the document. (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. Each author has stated prior the WG adoption poll and prior to the WGLC that all the IPRs they are are aware of has been disclosed according to the IETF disclosure process. (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 disclosed against this document, the working were made aware of this disclosure both in the working group pol and in the WGLC. There were no discussion on the IPR, this has been interpreted as that the WG are ready to move ahead with the document regardless of the IPR disclosure. (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 as a whole understand that this is something we need to specify to improve monitoring. The work has been done within a small group of people that form an overlap between the MPLS and TICTOC WG's. (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. We have one outdated informative refrence, but that document is currently active, and we should capture the correct version when the RFC is published. On the possible downward references see question 13. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes the references has been correctly split. (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 normative references are to existing RFCs, with the exception of the IEEE document mentioned in question 15. (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. The nits tool point at: [IEEE.1588.2008] "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, July 2008. as a possible down-ref (non-RFC), the shepherd does not think this a down-ref. After a short discussion between the shepherd and and one of ther authors we decided to put in the following clarification: Thereferenced document is a standard (they do have lower grade standards like we do) of the IEEE Instrumentation and Measurement Society. https://standards.ieee.org/findstds/standard/1588-2008.html FWIW TICTOC has an agreement that members of the WG can have access to the text for use in conjunction with their work in the IETF. (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 will be no changes of status of any other document. (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 document has an extensive (eight sub-section, with several IANA actions each) and well written IANA section The shepherd have reviewed the IANA section and the IANA work several times. The shepherd is convinced that all the criteria listed in question 17 are met and clearly stated. The document creates two new registries, and allocate code points from 6 (sub.)registries. All assignable code points are assign by the FCFS method. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new registries that requires Expert Review. (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. No such formal review necessary. |
2017-01-05
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2017-01-05
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2017-01-03
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2017-01-03
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2017-01-03
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-01-03
|
12 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "Loa Andersson" , … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "Loa Andersson" , loa@pi.nu Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Residence Time Measurement in MPLS network) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Residence Time Measurement in MPLS network' 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 2017-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2626/ |
2017-01-03
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-01-03
|
12 | Deborah Brungard | Placed on agenda for telechat - 2017-02-02 |
2017-01-03
|
12 | Deborah Brungard | Last call was requested |
2017-01-03
|
12 | Deborah Brungard | Ballot approval text was generated |
2017-01-03
|
12 | Deborah Brungard | Ballot writeup was generated |
2017-01-03
|
12 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2017-01-03
|
12 | Deborah Brungard | Last call announcement was generated |
2016-12-13
|
12 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-12.txt |
2016-12-13
|
12 | (System) | New version approved |
2016-12-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: "John Drake" , mpls-chairs@ietf.org, "Stefano Ruffini" , "Stewart Bryant" , "Sasha Vainshtein" , "Gregory Mirsky" , … Request for posting confirmation emailed to previous authors: "John Drake" , mpls-chairs@ietf.org, "Stefano Ruffini" , "Stewart Bryant" , "Sasha Vainshtein" , "Gregory Mirsky" , "Eric Gray" |
2016-12-13
|
12 | Greg Mirsky | Uploaded new revision |
2016-12-09
|
11 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: He Jia. |
2016-11-22
|
11 | Xian Zhang | Request for Early review by RTGDIR is assigned to He Jia |
2016-11-22
|
11 | Xian Zhang | Request for Early review by RTGDIR is assigned to He Jia |
2016-11-22
|
11 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2016-11-02
|
11 | Loa Andersson | The MPLS working group requests that Residence Time Measurement in MPLS network … The MPLS working group requests that Residence Time Measurement in MPLS network draft-ietf-mpls-residence-time 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? The intended type of RFC is Proposed Standard. The document specifies protocol and protocol information elements, so Proposed Standard is the proper type of RFC. The documet 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 Thie document specifies a G-ACh based Residence Time Measurement capability and how it can be used by time synchronization protocols being transported over an MPLS domain. The Associated Channel was first specified in MPLS PW context, was generalized during the MPLS-TP project and is now frequently used across the entire MPLS technology. "Residence time" is the variable part of propagation delay when timing and synchronization messages are propagated along a path in the network. Knowing what this part of the delay is for each message makes it possible to more accurately determine the delay value to be included in e.g. a Precision Time Protocol (PTP) event message. Working Group Summary The working group processing of this group was fairly smooth, though some experts in the area have ben chiming in and very much improved the document. Document Quality There has been no formal expert review. We are aware of intentions to implement this specification, an Implementation Poll has been started and the Write-Up will be as new information is available. Personnel Loa Andersson is the Document Shepherd. Deborah Brungard is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. In the MPLS working group the shepherd is appointed well before the working group adoption poll. The shepherd makes sure that the document is ready for the adoption poll (including detailed review and IPR poll). The shepherd follows the document closely and review the when necessary, particular interest is given to the IANA section and IPR disclosures. This particular was reviewed by the shepherd before the WG adoption poll, during the WG process and prior to the WGLC, the shepherd has also closely followed the updates to the document that were caused by these reviews. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No such reviews necessary, though we made sure that synchronization experts has reviewed the document. (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. Each author has stated prior the WG adoption poll and prior to the WGLC that all the IPRs they are are aware of has been disclosed according to the IETF disclosure process. (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 disclosed against this document, the working were made aware of this disclosure both in the working group pol and in the WGLC. There were no discussion on the IPR, this has been interpreted as that the WG are ready to move ahead with the document regardless of the IPR disclosure. (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 as a whole understand that this is something we need to specify to improve monitoring. The work has been done within a small group of people that form an overlap between the MPLS and TICTOC WG's. (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. We have one outdated informative refrence, but that document is currently active, and we should capture the correct version when the RFC is published. On the possible downward references see question 13. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews necessary. (13) Have all references within this document been identified as either normative or informative? Yes the references has been correctly split. (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 normative references are to existing RFCs, with the exception of the IEEE document mentioned in question 15. (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. The nits tool point at: [IEEE.1588.2008] "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, July 2008. as a possible down-ref (non-RFC), the shepherd does not think this a down-ref. After a short discussion between the shepherd and and one of ther authors we decided to put in the following clarification: Thereferenced document is a standard (they do have lower grade standards like we do) of the IEEE Instrumentation and Measurement Society. https://standards.ieee.org/findstds/standard/1588-2008.html FWIW TICTOC has an agreement that members of the WG can have access to the text for use in conjunction with their work in the IETF. (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 will be no changes of status of any other document. (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 document has an extensive (eight sub-section, with several IANA actions each) and well written IANA section The shepherd have reviewed the IANA section and the IANA work several times. The shepherd is convinced that all the criteria listed in question 17 are met and clearly stated. The document creates two new registries, and allocate code points from 6 (sub.)registries. All assignable code points are assign by the FCFS method. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new registries that requires Expert Review. (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. No such formal review necessary. |
2016-11-02
|
11 | Loa Andersson | Responsible AD changed to Deborah Brungard |
2016-11-02
|
11 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-11-02
|
11 | Loa Andersson | IESG state changed to Publication Requested |
2016-11-02
|
11 | Loa Andersson | IESG process started in state Publication Requested |
2016-11-02
|
11 | Loa Andersson | Changed document writeup |
2016-10-18
|
11 | Loa Andersson | Changed document writeup |
2016-07-20
|
11 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-11.txt |
2016-07-17
|
10 | Loa Andersson | Tag Other - see Comment Log cleared. |
2016-07-17
|
10 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2016-07-05
|
10 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-10.txt |
2016-06-27
|
09 | Loa Andersson | Waiting for reaction from authors on wg chair mail on output from the nits tool. |
2016-06-27
|
09 | Loa Andersson | Tag Other - see Comment Log set. |
2016-06-27
|
09 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2016-05-31
|
09 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2016-04-28
|
09 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-09.txt |
2016-04-28
|
08 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-08.txt |
2016-04-07
|
07 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-07.txt |
2016-03-18
|
06 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-06.txt |
2016-03-15
|
05 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-05.txt |
2016-02-18
|
04 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-04.txt |
2016-02-12
|
03 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-03.txt |
2016-02-10
|
02 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-02.txt |
2016-01-29
|
01 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-01.txt |
2015-11-16
|
00 | Loa Andersson | Notification list changed to "Loa Andersson" <loa@pi.nu> |
2015-11-16
|
00 | Loa Andersson | Document shepherd changed to Loa Andersson |
2015-08-04
|
00 | Loa Andersson | This document now replaces draft-mirsky-mpls-residence-time instead of None |
2015-08-04
|
00 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2015-08-04
|
00 | Greg Mirsky | New version available: draft-ietf-mpls-residence-time-00.txt |