Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks
draft-ietf-pwe3-p2mp-pw-requirements-10

[Ballot comment]

Thanks for adding the new security considerations text.

As a comment, I'd suggest one more tweak

OLD:

      The solution SHOULD provide means to guarantee the traffic delivery
to receivers (Integrity, Confidentially)

NEW:

      The solution SHOULD provide means to protect the traffic delivered
to receivers (Integrity, Confidentially, Endpoint Authentication)

Not quite a nit, but definitely not discuss-worthy.

[Ballot comment]
I don't think work covered by this requirements doc should go forward without resolving the outstanding IPR issue, but I'm not going to try to block the document—just registering my concern.

[Ballot comment]
I support Stephen's discuss and would like to see a response to the SecDir comments as well (one fits in as a question on a particular change in the security considerations from the referenced RFC and may help in Stephen's discuss).

[Ballot discuss]

Section 5 says that the security reqiurements have
not changed since 2004. That surprises me.  And the
referenced  3916 section 11 basically says "use IPsec
(maybe)." That also seems somewhat unlikely to
happen.  (Or is it? I'd be happy to hear its widely
implemented and deployed.) Assuming for a moment
IPsec usage is in fact rare, isn't there a need to
include confidentiality, data integrity and endpoint
authentication as requirements to be met?

[Ballot comment]
A nit: In the Abstract

  This document presents a set of requirements and a framework for
  providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet
  Switched Networks. The requirements identified in this document are
  related to architecture, signaling and maintenance aspects of Point-
  to-Multipoint PW operation. They are proposed as guidelines for the
  standardization of such mechanisms. Among other potential
  applications, Point-to-Multipoint PWs can be used to optimize the
  support of multicast layer 2 services (Virtual Private LAN Service
  and Virtual Private Multicast Service) as defined in the Layer 2
  Virtual Private Network Working Group.

I thought common practice was that we didn't refer to working groups (which conclude) in RFCs (that last forever)?

More than a nit, but not a Discuss: This draft contains a fair number of SHOULDs with no guidance on why you might not or what happens if you don't. I don't have anywhere near the background to question specific SHOULDs ... with maybe one or two exceptions, like:

3.4.5. Failure Detection and Reporting

  -  In case of failure, it SHOULD correctly report which Leaf PEs are
      affected.  This SHOULD be realized by enhancing existing PW
      methods, such as LDP Status Notification.  The notification
      message SHOULD include the type of fault (P2MP PW, AC or PSN
      tunnel).

Are there network operators who think it will be awesome to see failure reports that don't tell them what Leaf PEs are affected, or don't tell them the type of fault?

Maybe that's normal in the PW world, and that would be fine if it's true, but I'm imagining seeing a failure report that says "Something bad happened, but I can't tell you much about it. You should worry. Good luck on finding it" :D

[Ballot comment]
UPDATE: My comments below have been addressed in -09; thanks.

I'm happy to see this fine document approved.  I have two small comments, neither of which is a big deal:

1. In Section 3.4.7, you say

  The solution SHOULD scale at worst linearly with the number of Leaf
  PEs.

It's probably worth adding a few more words to say *what* should scale that way.  Maybe something like this (thanks to a conversation with Adrian):

  The solution SHOULD scale at worst linearly for message size, memory
  requirements, and processing requirements, with the number of Leaf PEs.

2. My sense of "normative references" are those that are necessary for a reader to understand the document at hand.  I think some of the informative references should be moved to normative, including 3985, 5659, 5332, and 3916.  I'm of mixed mind about 4446, 6310 -- they're targets of MUST clauses, but I'm on the fence about whether that alone makes them normative.

Anyway, please consider going through the informative references, and making a handful of the most critical ones be normative.

Both of these comments are non-blocking, so if you think it's fine as it is, carry on and you'll have no further discussion from me.  Thanks for considering....

[Ballot comment]
I'm happy to see this fine document approved.  I have two small comments, neither of which is a big deal:

1. In Section 3.4.7, you say

  The solution SHOULD scale at worst linearly with the number of Leaf
  PEs.

It's probably worth adding a few more words to say *what* should scale that way.  Maybe something like this (thanks to a conversation with Adrian):

  The solution SHOULD scale at worst linearly for message size, memory
  requirements, and processing requirements, with the number of Leaf PEs.

2. My sense of "normative references" are those that are necessary for a reader to understand the document at hand.  I think some of the informative references should be moved to normative, including 3985, 5659, 5332, and 3916.  I'm of mixed mind about 4446, 6310 -- they're targets of MUST clauses, but I'm on the fence about whether that alone makes them normative.

Anyway, please consider going through the informative references, and making a handful of the most critical ones be normative.

Both of these comments are non-blocking, so if you think it's fine as it is, carry on and you'll have no further discussion from me.  Thanks for considering....

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pwe3-p2mp-pw-requirements-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs) to Informational RFC


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Requirements and Framework for Point-to-Multipoint Pseudowires over
  MPLS PSNs'
  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-03-27. 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 a set of requirements and a framework for
  providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs.  The
  requirements identified in this document are related to architecture,
  signaling and maintenance aspects of Point-to-Multipoint PW
  operation.  They are proposed as guidelines for the standardization
  of such mechanisms.  Among other potential applications, Point-to-
  Multipoint PWs can be used to optimize the support of multicast layer
  2 services (Virtual Private LAN Service and Virtual Private Multicast
  Service) as defined in the Layer 2 Virtual Private Network Working
  Group.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-p2mp-pw-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-p2mp-pw-requirements/ballot/


The following IPR Declarations may be related to this I-D:
  http://datatracker.ietf.org/ipr/2249/

AD review
=====

Hi,

I have done my usual review as AD in support of the publication request
for this document. This is now a very solid document : all credit to the
authors and to Stewart's guidance.

As I have only a few minor nits with the text (shown below) I will start
the IETF last call and raise the issues there. You can address them
together with any other points that are raised during the last call.

Thanks for the work,
Adrian

===

PSN needs to be expanded in the title, Abstract, and Introduction.

Please check for other acronyms like OAM.

---

Since this is not a protocol specification, the RFC 2119 language does
not apply in the way described in RFC 2119. I suggest you replace
Section 1.3 with something like...

  Although this is a requirements specification not a protocol
  specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted to apply to
  protocol solutions designed to meet these requirements as described
  in [RFC2119] .

---

I have a question about the architecture and model shown in Figure 1.
Can the P2MP PW branch at an egress PE by having multiple attached ACs
leading to different CEs?

Perhaps this does not count as a branch in the PW, but it is a branch in
the service.

---

In Section 3.2

s/P-to-MP MPLS LSP/P2MP MPLS LSP/

---

Section 3.4.2 has...

  The Root PE and Leaf PEs of a P2MP PW MUST be configured with the
  same PW type as defined in [RFC4446] for P2P PW.  In case of a
  different type, a PE MUST abort attempts to establish the P2MP PW.

That seems a little drastic. Do you mean "MUST abort attempts to
attach the leaf PE to the PW"?

Similarly in 3.4.3.

---

Section 4 might usefully refer back to the discussion of OAM.

---

Section 5 is fine, but it is interesting to consider

  A solution MUST NOT allow a P2MP PW to be established to PEs that do
  not support P2MP PW functionality.  It MUST have a mechanism to
  report an error for incompatible PEs.

Does an egress PE even need to know that it is attached to a P2MP PW
rather than a P2P PW?

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

Informational. It's a requirements and frameworks draft, there is no protocol being
specified. Yes, it's on the title page.

(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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document presents a set of requirements and a framework for
providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs.  The
requirements identified in this document are related to architecture,
signaling and maintenance aspects of Point-to-Multipoint PW
operation.  They are proposed as guidelines for the standardization
of such mechanisms.  Among other potential applications, Point-to-
Multipoint PWs can be used to optimize the support of multicast layer
2 services (Virtual Private LAN Service and Virtual Private Multicast
Service) as defined in the Layer 2 Virtual Private Network Working
Group.

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?

This draft has taken a while as it required extensive rewriting by a new editor following
the previous time it was submitted to the IESG. This added quite a bit of time to the
process, but has greatly improved the quality of the draft.

There was a bit of controversy regarding a late IPR declaration. That is discussed in
section 8 below.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

As this is a requirements and framework draft, there can be no implementations.

Stewart Bryant deserves special mention as the AD that resulted in the document
largely being re-written, which improved its quality.

Personnel

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

Andy Malis 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 has worked with the authors through the draft's later
revisions, and proposed new text to clear the IPR situation discussed in section 8.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

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

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

None at this point.

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

Yes.

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

Yes. This IPR disclosure, #2249, came in very late in the process, and the inventors
were two of the co-authors. While one could argue that it's hard to worry about IPR
when there's no protocol being defined or anything to implement, the WG chairs (with
the consensus of the WG) decided to be extra cautious, and new text was written that
removed the optional procedure that was the subject of the IPR disclosure. Thus, to be
precise, that IPR disclosure no longer applies to the revision of the draft that is now
being submitted to the IESG, but rather to an earlier revision.

(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?

Yes, it has good WG consensus. Given the IPR and other discussions, the WG is very
aware of this draft.

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

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

There is one miscellaneous warning regarding pre-RFC5378 text. The -00 version of
this draft is dated 9/4/08, which is pre-RFC5378. The RFC Editor can ensure that the
proper boilerplate is used for this case.

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

N/A

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

Yes.

(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?

No, but there is one informative reference still in progress, draft-ietf-l2vpn-vpms-frmwk-
requirements-05. Note that this draft expired about 10 months ago. The IESG may
wish to simply remove this reference, or leave it as a work in progress and see if it can
be renewed or progressed.

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

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

No.

(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).

N/A

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

None.

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

N/A

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

Informational. It's a requirements and frameworks draft, there is no protocol being specified. Yes, it's on the title page.

(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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document presents a set of requirements and a framework for
providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs.  The
requirements identified in this document are related to architecture,
signaling and maintenance aspects of Point-to-Multipoint PW
operation.  They are proposed as guidelines for the standardization
of such mechanisms.  Among other potential applications, Point-to-
Multipoint PWs can be used to optimize the support of multicast layer
2 services (Virtual Private LAN Service and Virtual Private Multicast
Service) as defined in the Layer 2 Virtual Private Network Working
Group.

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?

This draft has taken a while as it required extensive rewriting by a new editor following the previous time it was submitted to the IESG. This added quite a bit of time to the process, but has greatly improved the quality of the draft.

There was a bit of controversy regarding a late IPR declaration. That is discussed in section 8 below.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

As this is a requirements and framework draft, there can be no implementations.

Stewart Bryant deserves special mention as the AD that resulted in the document largely being re-written, which improved its quality.

Personnel

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

Andy Malis, Stewart Bryant.

(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 has worked with the authors through the draft's later revisions, and proposed new text to clear the IPR situation discussed in section 8.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

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

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

None at this point.

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

Yes.

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

Yes. This IPR disclosure, #2249, came in very late in the process, and the inventors were two of the co-authors. While one could argue that it's hard to worry about IPR when there's no protocol being defined or anything to implement, the WG chairs (with the consensus of the WG) decided to be extra cautious, and new text was written that removed the optional procedure that was the subject of the IPR disclosure. Thus, to be precise, that IPR disclosure no longer applies to the revision of the draft that is now being submitted to the IESG, but rather to an earlier revision.

(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?

Yes, it has good WG consensus. Given the IPR and other discussions, the WG is very aware of this draft.

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

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

There is one miscellaneous warning regarding pre-RFC5378 text. The -00 version of this draft is dated 9/4/08, which is pre-RFC5378. The RFC Editor can ensure that the proper boilerplate is used for this case.

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

N/A

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

Yes.

(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?

No, but there is one informative reference still in progress, draft-ietf-l2vpn-vpms-frmwk-requirements-05. Note that this draft expired about 10 months ago. The IESG may wish to simply remove this reference, or leave it as a work in progress and see if it can be renewed or progressed.

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

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

No.

(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).

N/A

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

None.

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

N/A

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

Informational. It's a requirements and frameworks draft, there is no protocol being specified. Yes, it's on the title page.

(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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document presents a set of requirements and a framework for
providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs.  The
requirements identified in this document are related to architecture,
signaling and maintenance aspects of Point-to-Multipoint PW
operation.  They are proposed as guidelines for the standardization
of such mechanisms.  Among other potential applications, Point-to-
Multipoint PWs can be used to optimize the support of multicast layer
2 services (Virtual Private LAN Service and Virtual Private Multicast
Service) as defined in the Layer 2 Virtual Private Network Working
Group.

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?

This draft has taken a while as it required extensive rewriting by a new editor following the previous time it was submitted to the IESG. This added quite a bit of time to the process, but has greatly improved the quality of the draft.

There was a bit of controversy regarding a late IPR declaration. That is discussed in section 8 below.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

As this is a requirements and framework draft, there can be no implementations.

Stewart Bryant deserves special mention as the AD that resulted in the document largely being re-written, which improved its quality.

Personnel

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

Andy Malis, Stewart Bryant.

(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 has worked with the authors through the draft's later revisions, and proposed new text to clear the IPR situation discussed in section 8.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

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

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

None at this point.

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

Yes.

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

Yes. This IPR disclosure, #2249, came in very late in the process, and the inventors were two of the co-authors. While one could argue that it's hard to worry about IPR when there's no protocol being defined or anything to implement, the WG chairs (with the consensus of the WG) decided to be extra cautious, and new text was written that removed the optional procedure that was the subject of the IPR disclosure. Thus, to be precise, that IPR disclosure no longer applies to the revision of the draft that is now being submitted to the IESG, but rather to an earlier revision.

(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?

Yes, it has good WG consensus. Given the IPR and other discussions, the WG is very aware of this draft.

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

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

There is one miscellaneous warning regarding pre-RFC5378 text. The -00 version of this draft is dated 9/4/08, which is pre-RFC5378. The RFC Editor can ensure that the proper boilerplate is used for this case.

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

N/A

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

Yes.

(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?

No, but there is one informative reference still in progress, draft-ietf-l2vpn-vpms-frmwk-requirements-05. Note that this draft expired about 10 months ago. The IESG may wish to simply remove this reference, or leave it as a work in progress and see if it can be renewed or progressed.

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

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

No.

(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).

N/A

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

None.

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

N/A

State changed to AD is watching from AD Evaluation::Revised ID Needed.
Version 5 of this draft, which was submitted for publication requires significant rework before being ready for publication.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Andrew Malis, andrew.g.malis@verizon.com

Yes, I have reviewed the document and I believe it is ready for
forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has received adequate discussion and review. The
document went through last call in the PWE3 working group, and the
only comment received during last call was regarding a single typo,
which can be corrected following IESG review. That typo is:

In the title of section 4.2
replace "P2MP SS-PW Underlying Layer"
by "P2MP MS-PW Underlying Layer"

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns or issues.

(1.e) 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?

I am comfortable that the document represents WG consensus and has
been reviewed by a reasonable number of active WG participants.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None indicated.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document passes ID nits. This document is not subject to MIB
doctor or other reviews.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the references are split appropriately. All of the normative
references are to published RFCs, with no downrefs (the intended
category is Informational). The two informative references are both WG
drafts (but in other working groups).

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists. It does not request any new allocations.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections that use a formal language.

(1.k) 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 a set of requirements for providing a
Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge)
emulation. The requirements identified in this document are related to
architecture, signaling and maintenance aspects of a
Point-to-Multipoint PW operation. They are proposed as guidelines for
the standardization of such mechanisms. Among other potential
applications Point-to-Multipoint PWs SHOULD be used to optimize the
support of multicast services (Virtual Private LAN Service and Virtual
Private Multicast Service) as defined in the Layer 2 Virtual Private
Network working group.

This document is a product of the PWE3 working group.

This document is INFORMATIONAL.

Working Group Summary

One of the major ongoing projects in the PWE3 working group is
extending pseudowires from just a simple point-to-point connection to
also supporting point-to-multipoint connections. This draft provides
the requirements for these extensions; there is a separate draft,
draft-ietf-pwe3-p2mp-pw-00, which defines the necessary protocol
extensions.

Document Quality

There are no concerns about document quality.

Personnel

Who is the Document Shepherd for this document?

Andrew Malis, andrew.g.malis@verizon.com

Who is the Responsible Area Director?

Stewart Bryant