Skip to main content

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