[Ballot comment]
I am balloting No Objection on this document. There is nothing
fundamentally wrong with the procedures or the explanation, but I
have quite a number of WIBNI-style Comments that I have set out below.
I don't think that any of them should be used to hold up the document,
but I wish that the issues could be made to go away.

---

The formatting of this I-D seems to be strange around the left margin
and the top-of-page margins.

---

Does Dinesh really still work for Nortel?

---

The only names in the "Authors' Addresses" section should be those on
the front page. Other names should be moved to a new "Contributors"
section.

---

The guidelines for writing I-Ds say that the first section in the
document should be the Introduction.

I suspect that you have put the 2119 boilerplate first because you have
use 2119 language within the Intrduction. This probably points to the
fact that the Introduction is actually far more than an introduction,
but is actually an introduciton, a problem, statement, and an overview
of the solution.

My preference would be for some restructuring work to make the
separation of material cleaner, and the document a little more
approachable, but it is a long shot to ask you to do this at the end of
a long development sysle for this work. I would at least like you to
look again at the use of 2119 language in the Introduction. Do you
really need it?

For example:

When an Ethernet
AC is an Ethernet physical port, there MAY be some application of
Ethernet Link OAM [802.3].

Is that really a conformance rule for this specification, or just an
observation that could be written in Enlgish?

For example:

The procedures outlined in this document define the entry and exit
criteria for each of the four defect states with respect to
Ethernet ACs and corresponding PWs, and the consequent actions that
PE1 MUST support to properly interwork these defect states and
corresponding notification messages between the PW domain and the
Native Service (NS) domain.

The "MUST" is surely fine in plain English.

---

There seems to be a lot of duplicate material from RFC 6310. It is not
easy to tell what is new material and what has been reproduced for
reference.

On the whole, I am not a fan of reproducing material from one RFC in
another. If any discrepency is introduced there is an immediate problem
determining which is the correct version. My preference is to make
direct reference to the pre-existing material, rather than to reproduce
it.

Actually, I found it *really* hard to work out what material in this
document is tutorial, and what material is a new specification. In my
opinion, that really devalues this document. It certainly made my
review less thorough because it is unclear whether text like that in
section 5.1...

PE1 enters the AC Receive Defect state if any of the following
conditions is met:

...is a new definition of just commentary.

---

Does this document update RFC 6310? he distinguish factor is whether
you consider it makes sense to implement 6310 without this augmentation,
or if you consider that this document only provides additional function
for some cases such that 6310 is fine and fully functional without it.

---

Section 2
- Ethernet Local Management Interface {E-LMI} [MEF16]
Seems to use the wrong type of braces around E-LMI

---

You have two different meanings for "MEP" in this document.

---

The definition of MIP in Section 3.1 is surely wrong.

---

In 3.2 you say that a MIP cannot terminate an OAM frame. But I thought
that a MEP could send OAm specificially targetted at a MIP. It
certainly can in MPLS. Is it different in Ethernet? Or do you have
some special meaning for "terminate".

---

In Section 4 you have "MPLS-IP PSN". Is this what is normally called an
"IP/MPLS network" or is this a new term? And in this context is "MPLS
PSN" meant to mean an MPLS network that has no IP support?

---

A bit of nasty passive voice has crept in to Section 4.1

These NS OAM notifications are inserted into the corresponding PW.

Who inserts, and where in the network?

---

In 4.2

When PWs are established using the Label Distribution Protocol
(LDP), LDP status notification signaling MUST be used as the
default mechanism to signal AC and PW status and defects [RFC4447].

Is this restating 2119 language from RFC 4447, or is it making a new
specification requirement? I'm almost at the point of a Discuss with
this question, because if the answer is "new requirement" then I think
you are probably updating a number of RFCs. OTOH, if it is a
restatement, then you should not use 2119 language.

---

In 4.2

For PWs established over
an MPLS or MPLS-IP PSN using other mechanisms (e.g. static
configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be
used to convey AC and PW status and defects.

What are the alternatives to "SHOULD"? Please state them and note when
they can be used.

---

4.3

When using VCCV, the control channel (CC) type and Connectivity
Verification (CV) Type are agreed on between the peer PEs using the
VCC parameter field signaled as a sub-TLV of the interface
parameters TLV when using FEC 129 and the interface parameter sub-
TLV when using FEC 128.

This paragraph should have a citation.

Actually, I am not sure that anything in 4.3 is new material. Is it?

---

4.3
As defined in [RFC6310], when CV type of 0x04 0r 0x10 is used to
s/0r/or/

---

It is customary and really useful to add a note at the start of an
Appendix to indicate whether the material is informative or normative.