Skip to main content

Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
RFC 7412

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-smp-requirements@ietf.org to (None)
2014-12-12
09 (System) RFC published
2014-12-08
09 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7412">AUTH48-DONE</a> from AUTH48
2014-11-24
09 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7412">AUTH48</a> from RFC-EDITOR
2014-11-21
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-10-13
09 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-10-10
09 (System) RFC Editor state changed to EDIT
2014-10-10
09 (System) Announcement was received by RFC Editor
2014-10-10
09 (System) IANA Action state changed to No IC from In Progress
2014-10-10
09 (System) IANA Action state changed to In Progress
2014-10-10
09 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-10-10
09 Amy Vezza IESG has approved the document
2014-10-10
09 Amy Vezza Closed "Approve" ballot
2014-10-10
09 Adrian Farrel IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-10-10
09 Adrian Farrel Ballot writeup was changed
2014-10-10
09 Adrian Farrel Ballot approval text was generated
2014-09-28
09 Kathleen Moriarty [Ballot comment]
Thanks very much for addressing my discuss from the SecDir review and comments in the updated version.
2014-09-28
09 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2014-09-27
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-09-27
09 Jeong-dong Ryoo IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-09-27
09 Jeong-dong Ryoo New version available: draft-ietf-mpls-smp-requirements-09.txt
2014-08-18
08 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-08-11
08 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2014-08-07
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-08-07
08 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-08-07
08 Stephen Farrell
[Ballot comment]

I'm not sure I agree that there are no new security
considerations here. Say if the path ABCDE has some security
property (e.g. …
[Ballot comment]

I'm not sure I agree that there are no new security
considerations here. Say if the path ABCDE has some security
property (e.g. encrypted) then won't that also be a requirement
that APQRE will also need to be able to meet? And doesn't that
then impose some requirements on solutions?  So wouldn't it be
a good plan to add a requirement that solutions MUST be able to
ensure/manage commensurate security for protection paths? (This
is not a discuss because I'd be fine to raise such a discuss
ballot for a solution document, and also because it overlaps with
Kathleen's discuss with which I agree.)
2014-08-07
08 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-08-07
08 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-08-07
08 Kathleen Moriarty
[Ballot discuss]
I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing …
[Ballot discuss]
I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing to see if some text should be added to the Security Considerations section.

The request was to put more into the security considerations since this is a requirements draft.  The problems would be addressed in the specific solution drafts, but it would be good to call these issues out as security considerations for those solutions.

Possible text:

Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector to protect against.  Protections should also be considered to prevent a malicious actor from attempting to cause an alternate path to force traffic by a sensor/device, thereby enabling pervasive monitoring [RFC7258].


Here is the SecDir review for reference:
https://www.ietf.org/mail-archive/web/secdir/current/msg04864.html
2014-08-07
08 Kathleen Moriarty Ballot discuss text updated for Kathleen Moriarty
2014-08-07
08 Kathleen Moriarty
[Ballot discuss]
I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing …
[Ballot discuss]
I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing to see if some text should be added to the Security Considerations section.

The request was to put more into the security considerations since this is a requirements draft.  The problems would be addressed in the specific solution drafts, but it would be good to call these issues out as security considerations for those solutions.

Possible text:

Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector to protect against.  Protections should also be considered to prevent a malicious actor from attempting to cause an alternate path to force traffic by a sensor/device, thereby enabling pervasive monitoring [RFC7258].
2014-08-07
08 Kathleen Moriarty
[Ballot comment]
Could you add a small amount of text into the introduction so that it is clear that the term protection used in this …
[Ballot comment]
Could you add a small amount of text into the introduction so that it is clear that the term protection used in this draft is referring to survivability or availability?  Or a reference to it would be helpful as was done in the second paragraph of the introduction of RFC6378.  Text is preferred though since this should be very simple to address with a few words.

As a security person, I was mapping out paths and trying to figure out if certain resources had special properties I didn't see described anywhere until I got a bit further into the draft to realize they were really just alternate paths.  I am sure this wouldn't be an issue for those well-versed in MPLS, but could be helpful for the rest of us.
2014-08-07
08 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2014-08-06
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-08-06
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-08-05
08 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-07-31
08 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-07-31
08 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-07-30
08 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-07-30
08 Adrian Farrel Ballot has been issued
2014-07-30
08 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-07-30
08 Adrian Farrel Created "Approve" ballot
2014-07-30
08 Adrian Farrel Placed on agenda for telechat - 2014-08-07
2014-07-30
08 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2014-07-30
08 Adrian Farrel Ballot writeup was changed
2014-07-30
08 Adrian Farrel Changed consensus to Yes from Unknown
2014-07-25
08 Jeong-dong Ryoo New version available: draft-ietf-mpls-smp-requirements-08.txt
2014-07-22
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-07-22
07 Jeong-dong Ryoo IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-07-22
07 Jeong-dong Ryoo New version available: draft-ietf-mpls-smp-requirements-07.txt
2014-06-26
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Christopher Inacio.
2014-06-23
06 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2014-06-23
06 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2014-06-23
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-06-13
06 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-06-13
06 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-06-12
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-06-12
06 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-smp-requirements-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-smp-requirements-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2014-06-12
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Inacio
2014-06-12
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Inacio
2014-06-11
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joe Abley
2014-06-11
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joe Abley
2014-06-10
06 Jeong-dong Ryoo New version available: draft-ietf-mpls-smp-requirements-06.txt
2014-06-09
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-06-09
05 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-mpls-smp-requirements-05.txt> (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Requirements for MPLS-TP Shared Mesh Protection'
  <draft-ietf-mpls-smp-requirements-05.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-23. 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 presents the basic network objectives for the behavior
  of shared mesh protection (SMP) which are not based on control plane
  support. This is an expansion of the basic requirements presented in
  RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC
  6372
"MPLS Transport Profile (MPLS-TP) Survivability Framework".
  This document is to be used as a basis for the definition of any
  mechanism that would be used to implement SMP for MPLS-TP data paths,
  in networks that delegate executive action for resiliency to the data
  plane.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ballot/


No IPR declarations have been submitted directly on this I-D.
2014-06-09
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-06-08
05 Adrian Farrel Last call was requested
2014-06-08
05 Adrian Farrel Ballot approval text was generated
2014-06-08
05 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation
2014-06-08
05 Adrian Farrel Last call announcement was changed
2014-06-08
05 Adrian Farrel Last call announcement was generated
2014-06-08
05 Adrian Farrel Last call announcement was generated
2014-06-08
05 Adrian Farrel
AD review
=========

Hi authors,

I have done my usual review of your document having received the
publication request. The purpose of my review is …
AD review
=========

Hi authors,

I have done my usual review of your document having received the
publication request. The purpose of my review is to improve the
quality of the document and to catch any issues that might otherwise
show up during IETF last call, Directorate reviews, or IESG evaluation.

This is a pretty good document. Thanks for the effort you have put in,
and thanks to Matt for working on the English. He deserves an
acknowledgement somewhere in the document.

I have only a few issues, and they don't merit a new revision now.
So I will start the IETF last call and raise these points to be
addressed at that time.

Thanks,
Adrian

---

Could you expand "p2p" where it is first used?

---

The very first sentence is hard to parse

  MPLS transport networks can be characterized as being a network of
  connections between nodes within a mesh of nodes and the links
  between them.

Maybe try

  The MPLS Transport Profile (MPLS-TP) provides tools to construct and
  operate a set of connections between nodes in an MPLS network.  The
  MPLS network is a mesh comprising nodes and the links between them.

---

I understand that you want to use RFC 2119 language to clarify the
requirements, but RFC 2119 was developed for specifying protocols, so
the direct reference and boilerplate quote is incongruous. I suggest
you use the language as found in RFC 5654, viz.:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].
  Although this document is not a protocol specification, the use of
  this language clarifies the instructions to protocol designers
  producing solutions that satisfy the requirements set out in this
  document.

---

In Section 5.1 you have

  the control
  protocol SHOULD NOT be used as the primary resilience mechanism.

I agree, but I think that the term "primary resilience mechanism" may be
under defined. Can you do anything to clarify this? Maybe...

  the control
  protocol SHOULD NOT be used as the primary mechanism for detecting or
  reporting network failures, or for initiating or coordinating
  protection switch-over.  That is, it SHOULD NOT be used as the
  primary resilience mechanism.
2014-06-07
05 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2014-06-07
05 Adrian Farrel Ballot writeup was changed
2014-06-07
05 Adrian Farrel Ballot writeup was generated
2014-06-07
05 Adrian Farrel
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
          …
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
                draft-ietf-mpls-smp-requirements-05.txt

  Is published as an Informational RFC with IETF consensus.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This is a requirement specification and should be published as an
  Informational RFC with IETF consensus.

  The document header says "Informational".

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents the basic objectives of shared mesh protection
  (SMP) that can be utilized without dependence on a control plane. The document
  expands the requirements of RFC 5654 "Requirements for the Transport Profile
  of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability
  Framework".

  The intention is that this document shall be used when defining mechanisms that
  use SMP to implement protection for MPLS-TP data paths, in networks that
  delegate executive action for resiliency to the data plane.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The history of MPLS-TP SMP includes starting out with a number
  of solution drafts, some which were fairly quickly merged, but we failed
  to merge all solutions into a single document.

  The advice from the working group chairs at this point was to start with
  a requirement specification. The current document is the result of that
  process and includes authors from across the solutions drafts.

  The document has been well discussed in the part of the MPLS WG that
  is interested in MPLS-TP style protection.

  The only "out of the ordinary" thing that has happened is that at one point
  in time some of the authors told me that "the document is ready for wglc".
  In preparation for the wglc the shepherd started an IPR poll saying:

  "The authors of draft-ietf-mpls-smp-requirements have told the
    working group chairs that the draft is ready to be working
    group last called.

    Before starting the the wglc we need to do an IPR poll."

  Resulting in that one author and one contributor notified the shepherd that
  they did not believe the document was ready to go!

  Well - this was sorted out and all comments addressed.

Document Quality

  This document is a requirement specification, and as such is not possible
  to implement. It has been claimed in the discussion that led up to merging
  solutions documents and requirement that some of the existing MPLS-TP
  protection implementations fulfill the requirements in this draft.

  The discussion on implementations will be revisited if and when we see
  solutions addressing the requirements in this document being put forward.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Andersson is the Document Shepherd.
  Adrian Farrel is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd believes this document is ready for publication
  as an Informational RFC. Since the ITU-T SG15 is interested to use it as
  a reference, it should go through IETF Last Call.

  The document shepherd has reviewed this and related documents several
  times since the discussion on MPLS-TP shared mesh protection started
  in 2010. The Shepherd has also been participating in the efforts to merge
  the solutions document and establish requirement document.

  The Shepherd has the impression that there is a strong vendor and operator
  interest in this area, and that this set of requirements represents a least
  common denominator.

  The Document Shepherd reviewed the document prior to the WG Adoption poll
  and prior to wglc. When preparing the Shepherd Write-up for version -04, the
  document shepherd decided that a langue review were needed and version
  -05 is the result of this review performed by Matt Hartley.The language review
  has very much improved the document.

(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 review needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No real concerns, the only thing is that the document need to go through
  an full IETF Last Call in order to be possible for ITU-T to use it as a
  reference.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors and contributors have stated on the working group mailing
  list that they are unaware of any IPR against this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures filed against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  In the part of the working group that is interested in MPLS-TP protection
  the consensus is very strong, in the part of the working group more
  interested  IP/MPLS FRR and by-pass, the document is less well reviewed
  but I'd say that based on the checks I've done no issues with progressing
  the document have emerged.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The nits tools points gives on warning, an unexpected double-space
  on line 154. I think that this can be updated by the RFC Editor or if
  new revisions are needed down the line.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  There are only normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All (normative) references are to existing RFC or to stable ITU-T
  Recommendations.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references!

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There are no documents for which the status will be changed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA allocations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such reviews performed.
2014-06-07
05 Adrian Farrel
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
          …
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
                draft-ietf-mpls-smp-requirements-05.txt

  Is published as an Informational RFC with IETF consensus.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This is a requirement specification and should be published as an
  Informational RFC with IETF consensus.

  The document header says "Informational".

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents the basic objectives of shared mesh protection
  (SMP) that can be utilized without dependence on a control plane. The document
  expands the requirements of RFC 5654 "Requirements for the Transport Profile
  of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability
  Framework".

  The intention is that this document shall be used when defining mechanisms that
  use SMP to implement protection for MPLS-TP data paths, in networks that
  delegate executive action for resiliency to the data plane.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The history of MPLS-TP SMP includes starting out with a number
  of solution drafts, some which were fairly quickly merged, but we failed
  to merge all solutions into a single document.

  The advice from the working group chairs at this point was to start with
  a requirement specification. The current document is the result of that
  process.

  The document has been well discussed in the part of the MPLS WG that
  is interested in MPLS-TP style protection.

Document Quality

  This document is a requirement specification, and as such is not possible
  to implement. It has been claimed in the discussion that led up to merging
  solutions documents and requirement that some of the existing MPLS-TP
  protection implementations fulfill the requirements in this draft.

  The discussion on implementations will be revisited if and when we see
  solutions addressing the requirements in this document being put forward.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Andersson is the Document Shepherd.
  Adrian Farrel is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd believes this document is ready for publication
  as an Informational RFC. Since the ITU-T SG15 is interested to use it as
  a reference, it should go through IETF Last Call.

  The document shepherd have reviewed this and related documents several
  times since the discussion on MPLS-TP shared mesh protection started
  in 2010. The Shepherd has also been participating in the efforts to merge
  the solutions document and establish requirement document.

  The Shepherd has the impression that there is a strong vendor and operator
  interest in this area, and that this set of requirements represents a least
  common denominator.

  The Document Shepherd reviewed the document prior to the WG Adoption poll
  and prior to wglc. When preparing the Shepherd Write-up for version -04, the
  document shepherd decided that a langue review were needed and version
  -05 is the result of this review performed by Matt Hartley.The language review
  have very much improved the document.

(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 review needed.

  The only "out of the ordinary" thing that has happened is that at one point
  in time some of the authors told me that "the document is ready for wglc".
  In preparation for the wglc the shepherd started an IPR poll saying:

  "The authors of draft-ietf-mpls-smp-requirements has told the
    working group chairs that the draft is ready to be working
    group last called.

    Before starting the the wglc we need to do an IPR poll."

  Resulting in that one author and one contributor notified the shepherd that
  they did not believe the document was ready to go!

  Well - this was sorted out and all comments addressed.

(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 real concerns, the only thing is that the document need to go through
  an full IETF Last Call in order to be possible for ITU-T to use it as a
  reference.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors and contributors have stated on the working group mailing
  list that they are unaware of any IPR against this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures filed against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  In the part of the working group that is interested in MPLS-TP protection
  the consensus is very strong, in the part of the working group more
  interested  IP/MPLS FRR and by-pass, the document is less well reviewed
  but I'd say that based on the checks I've done no issues with progressing
  the document have emerged.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The nits tools points gives on warning, an unexpected double-space
  on line 154. I think that this can be updated by the RFC Editor or if
  new revisions are needed down the line.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  There are only normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All (normative) references are to existing RFC or to stable ITU-T
  Recommendations.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references!

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There are no documents for which the status will be changed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA allocations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such reviews performed.
2014-06-04
05 Loa Andersson Document shepherd changed to Loa Andersson
2014-06-03
05 Loa Andersson
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
          …
  The MPLS working group requests that
 
            Requirements for MPLS-TP Shared Mesh Protection
                draft-ietf-mpls-smp-requirements-05.txt

  Is published as an Informational RFC with IETF consensus.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This is a requirement specification and should be published as an
  Informational RFC with IETF consensus.

  The document header says "Informational".

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  This document presents the basic objectives of shared mesh protection
  (SMP) that can be utilized without dependence on a control plane. The document
  expands the requirements of RFC 5654 "Requirements for the Transport Profile
  of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability
  Framework".
  The intention is that this document shall be used when defining mechanisms that
  use SMP to implement protection for MPLS-TP data paths,

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The history of MPLS-TP SMP includes starting out with a number
  of solution drafts, some which were fairly quickly merged, but we failed
  to merge all solutions into a single document.

  The advice from the working group chairs at this point was to start with
  a requirement specification. The current document is the result of that
  process.

  The document has been well discussed in the part of the MPLS WG that
  is interested in MPLS-TP style protection.

Document Quality

  This document is a requirement specification, and as such is not possible
  to implement. It has been claimed in the discussion that led up to merging
  solutions documents and requirement that some of the existing MPLS-TP
  protection implementations fulfill the requirements in this draft.

  The discussion on implementations will be revisited if and when we see
  solutions addressing the requirements in this document being put forward.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Andersson is the Document Shepherd.
  Adrian Farrel is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd believes this document is ready for publication
  as an Informational RFC. Since the ITU-T SG15 is interested to use it as
  a reference, it should go through IETF Last Call.

  The document shepherd have reviewed this and related documents several
  times since the discussion on MPLS-TP shared mesh protection started
  in 2010. The Shepherd has also been participating in the efforts to merge
  the solutions document and establish requirement document.

  The Shepherd has the impression that there is a strong vendor and operator
  interest in this area, and that this set of requirements represents a least
  common denominator.

  The Document Shepherd reviewed the document prior to the WG Adoption poll
  and prior to wglc. When preparing the Shepherd Write-up for version -04, the
  document shepherd decided that a langue review were needed and version
  -05 is the result of this review performed by Matt Hartley.The language review
  have very much improved the document.

(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 review needed.

  The only "out of the ordinary" thing that has happened is that at one point
  in time some of the authors told me that "the document is ready for wglc".
  In preparation for the wglc the shepherd started an IPR poll saying:

  "The authors of draft-ietf-mpls-smp-requirements has told the
    working group chairs that the draft is ready to be working
    group last called.

    Before starting the the wglc we need to do an IPR poll."

  Resulting in that one author and one contributor notified the shepherd that
  they did not believe the document was ready to go!

  Well - this was sorted out and all comments addressed.

(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 real concerns, the only thing is that the document need to go through
  an full IETF Last Call in order to be possible for ITU-T to use it as a
  reference.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors and contributors have stated on the working group mailing
  list that they are unaware of any IPR against this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures filed against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  In the part of the working group that is interested in MPLS-TP protection
  the consensus is very strong, in the part of the working group more
  interested  IP/MPLS FRR and by-pass, the document is less well reviewed
  but I'd say that based on the checks I've done no issues with progressing
  the document have emerged.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The nits tools points gives on warning, an unexpected double-space
  on line 154. I think that this can be updated by the RFC Editor or if
  new revisions are needed down the line.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  There are only normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All (normative) references are to existing RFC or to stable ITU-T
  Recommendations.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references!

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There are no documents for which the status will be changed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA allocations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such reviews performed.
2014-06-03
05 Loa Andersson State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-smp-requirements@tools.ietf.org
2014-06-03
05 Loa Andersson Responsible AD changed to Adrian Farrel
2014-06-03
05 Loa Andersson IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-06-03
05 Loa Andersson IESG state changed to Publication Requested
2014-06-03
05 Loa Andersson IESG process started in state Publication Requested
2014-06-03
05 Loa Andersson Changed document writeup
2014-06-02
05 Loa Andersson Changed document writeup
2014-06-01
05 Loa Andersson Changed document writeup
2014-06-01
05 Loa Andersson Changed document writeup
2014-06-01
05 Loa Andersson Changed document writeup
2014-06-01
05 Loa Andersson Tag Revised I-D Needed - Issue raised by WG cleared.
2014-06-01
05 Loa Andersson Changed document writeup
2014-05-30
05 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-05.txt
2014-04-30
04 Loa Andersson Tag Revised I-D Needed - Issue raised by WG set.
2014-03-14
04 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-04.txt
2014-01-31
03 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC cleared.
2014-01-31
03 Loa Andersson IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2014-01-31
03 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-03.txt
2014-01-05
02 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC set.
2014-01-05
02 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2013-12-12
02 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2013-12-12
02 Loa Andersson Annotation tag Revised I-D Needed - Issue raised by WG cleared.
2013-12-09
02 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-02.txt
2013-11-07
01 Loa Andersson Annotation tag Revised I-D Needed - Issue raised by WG set.
2013-11-07
01 Loa Andersson Intended Status changed to Informational from None
2013-09-27
01 Martin Vigoureux Document shepherd changed to Loa Andersson
2013-09-23
01 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-01.txt
2013-03-26
00 Sam Aldrin New version available: draft-ietf-mpls-smp-requirements-00.txt