I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< 

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-opsawg-oam-overview-14.txt
Reviewer: Elwyn Davies
Review Date: 21 March 2014
IETF LC End Date: Jan 2013
IESG Telechat date: 27 March 2014

Summary:
Ready with nits and a couple of very minor issues.
I was pleased that this version of the document seems to have been
greatly improved since -08 which I reviewed previously in Jan 2013, and
the scope is now quite clear.  Thanks for the work that has been done!  

Major issues:
None.

Minor issues:
General:  I wondered about the wisdom of using more or less mnemonic
tags for the multitude of references but on reflection the mnemonic
value is probably worthwhile.  I toyed with the idea of adding the RFC
number next to the reference in the text on first occurrence so that
people don't have to keep skipping off to the references, but in the end
this is probably a silly idea.

s2.2.9, Discussion: The added complexity of P2MP is called out but
nothing is said about MP2MP, which I think would be even more tricky.
Would it be useful to say something also about MP2MP? [*Are* there any
tools for this case?]

s4.4.1, para 6: There seems to be possibly a minor contradiction between
the statements:

> LSP Ping is easily extensible to
>    include additional information needed to support new functionality,
>    by use of Type-Length-Value (TLV) constructs.

and

> The usage of TLVs is
>    typically not easy to perform in hardware, and is thus typically
>    handled by the control plane.

What is the implication of adding a new TLV as regards hardware and
performance? Does the second statement mean that either the hardware
will throw away messages with unknown, new TLVs, complain about such
messages or have poor performance?  If so, the "easily" in the first
statement is possibly "easily but impractically".  A little explanation
is probably needed (or maybe this is just too complex to explain here).
Maybe reducing all this to "LSP Ping is extensible using additional TLVs
but there may be hardware issues (see RFC...)." 

Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/ (a couple of missing cases)

General: It would be helpful to use non-breaking hyphens in MPLS-TP and
all references if possible.

s1.2, first bullet: s/Standard development/Standards development/

s1.3: It would be useful to put a forward reference to the terminology
section 2.1 to cover the various acronyms and abbreviations in Table 1.

s3, 2nd bullet: s/also allows to detect/also allows detection of/  It
might also be appropriate to be a bit less definite about localization -
add in 'attempts' or 'tries' maybe?

s3, Delay Measurement: Maybe mention 'jitter' as an alternative for
delay variation.

s4.3.3, 2nd bullet: s/a failure is detected/a failure is reported/

s4.3.3, last para: s/i.e. no failures are detected,/i.e., when no
failures have been detected,/

s4.3.3, last para: "...negotiated transmission time" Do you mean
"transmission rate" as mentioned in the previous para?  If not it might
be good to make it clear that this isn't a typo.

s4.4.1, para 4 (after 2nd bullet): s/and also Maximum Transmission Unit
(MTU) problems/and also identify Maximum Transmission Unit (MTU)
problems/

s4.4.1, para 5: s/the MPLS faults/MPLS faults/

s4.5.1, 2nd bullet: 
> and there is a need to
>       differentiate OAM packets from data plane ones.
This is slightly confusing - the congruence requirement makes all the
packets (OAM and user) to be data plane packets. How about:

> and there is a need to
>       differentiate OAM packets from ordinary user packets in the data plane.


s4.5.1, Maintencance Intermediate Point section:
> A MIP in MPLS-TP identifies OAM packets destined
>    to it by the value of the TTL field in the OAM packet.
This is not terribly helpful: Either a reference to where to find out
what TTL value is needed or some explanation of the required value would
be a good idea.

s4.5.1, Up and Down MEPs:
The term "bridge interface" is IEEE/MPLS-TP jargon and needs defining.
Might be also worth a note that, unlike prior usage of up/down, this has
nothing to do with defects (or layabout parliamentarians in
Brussels). ;-)

s4.5.3: Please add a reference for PWE3 ACH and VCCV and a pointer to a
document where "PW control word" is defined (preferably with section
numbers.

s4.5.4.6: s/if there a return path exists/if a return path exists/

s4.7.3, last para: s/Server accepts the modes./Server accepts the mode./

s4.7.3, last para: I think there is a bit of interaction missing: (i)
server tells Session-sender to start sending; (ii) if Control-client
stops the session, it tells server and server tells Session-sender;
(iii) when session is finished Session-sender reports to Server which
recovers data from Session-receiver (or controls Fetch client?) 

s5.1, Traceroute: Should this mention the Paris traceroute?

s5.1, OWAMP/TWAMP: For consistency should probably reference RFCs.

s5.3: s/in as much accuracy/with as much accuracy/