Wildcard Pseudowire Type
RFC 4863

[Ballot comment]
3.1. Procedures when sending the wildcard FEC
...
  If the PW Type cannot be supported or is "wildcard" it MUST respond
  to this message with a Label Release message with an LDP Status Code
  of "Generic Misconfiguration Error".  Further actions are beyond the
  scope of this document but could include notifying the associated
  application (if any) or notifying network management.

This will be difficult for human diagnosis. Wouldn't it be better
to use a specific error code indicating a wildcard inconsistency?
(Same comment applies to section 3.2.)

[Ballot discuss]
The document includes a DOWNREF to Informational Normative Reference: RFC 3985 (ref. 'ARCH'). This is mentioned actually in the PROTO write-up with a mention to be fixed with a RFC Editor note, but I do not see the note yet in the write-up.

IANA Last Call Comments;

As described in the IANA Considerations section, we understand this
document requires a single action to be completed upon its approval.

In the Pseudo Wires Name Spaces registry located at:

http://www.iana.org/assignments/pwe3-parameters

in the subregistry named, MPLS Pseudowire Types Registry IANA will
add a new entry:

PW Type Description
------------- -----------------------
TBA Wildcard

The IANA notes that the document suggests a value for the new entry
(0x7FFF).  IANA understands that this is the only action required upon
approval of this document.

PROTO Write-up

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

Stewart Bryant (stbryant@cisco.com) is the Shepherd. I have
reviewed the document and it is ready 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?

This document has been reviewed by the WG, both through the LC
process, and at IETF WG meetings. There were no comments during the
three week LC that just completed. I have no concerns about state
of readiness of this document.

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

The document is ready to go.

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

The document is needed by the MFA who have unofficially, but
specifically requested that we expedite it from this point forward.

(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 beleive that the document is fully understood and supported.

(1.f) 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
entered into the ID Tracker.)

No one has indicated that they propose to appeal.

(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 boiler plate is pre-1-Feb-2007, but is technically still OK to move
to the next stage, and there are some minor page length issues.
However the document is fully readable, and I request that we continue
with the process, and correct these if IETF LC requires a respin.

(1.h) Has the document split its references into normative and
informative?

Yes, but RFC3895 should be informative, as it is an informational.
This can be corrected by a minor editor's note.

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

All references are existing RFCs

(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 suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. 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 section is sufficient and correct.

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

Not applicable.

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

Technical Summary

Pseudowire signaling requires that the Pseudowire Type (PW Type) be
identical in both directions. For certain applications the
configuration of the PW Type is most easily accomplished by
configuring this information at just one PW endpoint. In any form of
LDP-based signaling, each PW endpoint must initiate the creation of a
unidirectional LSP. In order to allow the initiation of these two
LSPs to remain independent, a means of allowing the PW endpoint
lacking a priori knowledge of the PW Type to initiate the creation of
an LSP is needed. This document defines a Wildcard PW Type to
satisfy this need.

Working Group Summary

This document has been reviewed by the experts in the PWE3 WG. It
has been explicitly requested by the MFA that we expedite completion
as they need to reference it in their work.

Protocol Quality

This is a very simple and well written extension to the PWE3
signalling protocol. No protocol issues are anticipated.

Personnel
Who is the Document Shepherd for this document?
Stewart Bryant (stbryant@cisco.com)

Who is the Responsible Area Director?
Mark Townsley (townsley@cisco.com)