Definitions of Textual Conventions for Pseudowire (PW) Management
draft-ietf-pwe3-pw-tc-mib-15

[Ballot comment]
I'm confused why some names are plain (e.g., PwGroupID) and some
end with a -Type (e.g., PwIDType) and yet the underlying types
and usage seem exactly the same. Was there some reason that
I missed?

I share Bert's concern about VLAN ID space. (Also, I though IEEE had
an extension to go beyond 4K VLANs. Is this so? How would that work with
VLAN IDs defined in this document?)

[Ballot comment]
Section 1., paragraph 2:
>    Comments should be made directly to the PWE3 mailing list at
>    pwe3@ietf.org.

  Remove this paragraph before the RFC gets published.

[Ballot discuss]
This DISCUSS is based on the comment made by Bert Wijnen on the MIB Doctors list.

  PwVlanCfg ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS      current
    DESCRIPTION
          "VLAN configuration for Ethernet PW.
          Values between 0 and 4095 indicate the actual VLAN field
          value.
          A value of 4096 indicates that the object refers to
          untagged frames, i.e., frames without a 802.1Q field.
          A value of 4097 indicates that the object is not
          relevant."
    SYNTAX  Unsigned32 (0..4097)

It is not clear why the PWE3 MIBs need another VLAN TC than the ones defined in RFC4363. It is also not clear how this is compatible with the IEEE 802.1

According to IEEE802.1 the values 0 and 4095 are not permitted on the wire in the VLAN-ID field in 802.1 PDUs. Are they allowed in Ethernet PW? It seems better to stay in sync with real VLAN technology and not allow the values zero and 4095.

Moreover, in the IEEE8021-TC-MIB which is on its way to be approved by the IEEE as part of P802.1ap the IEEE8021VlanIndexOrWildcard TC uses values 4096, 4097 as indices that represent VLANs with local scope. So there are risks that in the future these values 4096 and 4097 might cause trouble.

If we look at RFC4363, we see TCs for VlanId, VlanIdOrAny and VlanIdOrAnyOrNone. It seems that the VlanIdOrAnyOrNone would be a good TC for PWE3 to use where they make 0 to mean Untagged and 4095 to mean object is not relevant.

Note that a change in this document affects the pwe3-enet-mib which was already approved by the IESG.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignments in the "NETWORK MANAGEMENT PARAMETERS" registry located at
http://www.iana.org/assignments/smi-numbers
sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2.transmission (1.3.6.1.2.1.10)"

Decimal Name Description
------- ---- -----------
[tbd] pwTcStdMIB PW-TC-STD-MIB [RFC-pwe3-pw-tc-mib-12]

We understand the above to be the only IANA Action for 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?

Danny McPherson (danny@tcb.net) 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 (ending 2007-06-19), and at IETF WG meetings. There were
minor comments during the two week LC that has completed. Of the
comments, one was related to consistent use of the term "pseudowire",
which it was agreed would be made consistent when RFC Editor
review occurs, or if a respin is necessary after MIB Doctor review. The
other comments were addressed in response to the query and seem
to have satisfied the initiator.

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?

I have no concerns regarding the requirement for further review of
this document, although MIB Doctor review needs to occur and a
good bit of coordination has already occurred on that front per
MIB Doctor author participation on this document.

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

I have no specific concerns about this document, nor are there
concerns that should be conveyed to the IESG or Responsible AD.

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

This document is fully understood and supported by the PWE3
WG. There is no contention as to whether this work provides and
it is generally supported across the WG.

(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 to the WG chairs or WG mailing list that they
have intentions of appealing any proposed publication of this
document.

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

Yes. As a matter of fact, an updated ID correcting earlier ID nits
was provided by the authors several revisions ago.

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

Yes.

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

No.

(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 Consideration Section of the document provides the
following IANA and RFC Editor Guidance, which we believe to
be straight-forward and reasonable:

Editor's Note (to be removed prior to publication): The IANA is
requested to assign a value for "XXXX" under the 'transmission'
subtree and to record the assignment in the SMI Numbers registry.
When the assignment has been made, the RFC Editor is asked to
replace
"XXXX" (here and in the MIB module) with the assigned value and to
remove this note.

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

No, although we have verified this with the authors. We have
performed a preliminary MIB Doctor review by having Orly Nicklass
review the MIBs in detail, and made many changes based on her
suggestions. We have verified that they compile with SMICng,
and is clean using SmiLint.

(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

This document defines a Management Information Base (MIB) module which
contains Textual Conventions (TCs) to represent commonly-used Pseudo
Wire (PW) management information. The intent is that these TCs will
be imported and used in PW-related MIB modules that would otherwise

Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

Protocol Quality

This is a very simple and well written, no protocol issues are
anticipated and no outstanding technical issues exist..

Personnel
Who is the Document Shepherd for this document?

Danny McPherson (danny@tcb.net)

Who is the Responsible Area Director?

Mark Townsley (townsley@cisco.com)