Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16

I have one minor (almost trivial) comment/question, and several nits:

Comment:
=========
- 4.1, paragraph 3:
Is it reasonable for a TLV in this standards-action registry to be have sub-tlvs with reduced registration requirements?  (And if so, is there a reason to exclude specifications that are not RFCs?)

Nits:
====
-1, paragraph 1:
Missing "the" before "MPLS Transport Profile "

- 1.0, last paragraph, last two sentences:
Who are “we” in these sentences? Does it make sense to talk about what “we” are or are not “configuring”?

2.1.1, first bullet in first list:
consider s/"both sides should be"/"both sides are"

-4.1, 2nd paragraph, first sentence:
Missing words? (What is IANA requested to do with the TLV? I assume register it. Also, what is the name of the new TLV?
Consider a cross-reference to table to for "this sub-registry"

-4.2: "Assignments of bit positions 0 through 31"
If I read correctly, that's all the bits. Is this the same as saying the registry itself requires standards-action?

-5:
It's mildly odd to find the acknowledgements section between two substantive sections.

-6, first paragraph:
Should "liveliness" be "liveness"?

Mehmet Ersue performed the opsdir review.

- 2.1.1, is there any chance of moving on from the "Keyed SHA1"
from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying 
to get that kind of transition done as we can and moving to use of
a standard integrity check rather than a more home-grown one
has some benefits. The HMAC-SHA1-like thing you're doing is
still probably ok, (though could maybe do with crypto eyeballs
on it as there may have been relevant new results since 2010)
but future-proofing would suggest moving to HMAC-SHA256 if we
can. (I can imagine such a change might require a new document,
but am asking anyway:-)

- 2.1.1, I'd recommend saying any password auth-type MUST NOT
be used - would that be possible?

- section 6 - what "established secure key-exchange protocol"
is available to use here?

- (this is sort of off-topic) I find an architecture like this
where a packet traversing a network has quite so many
side-effects a bit hard to grok. Do you have a pointer to
something (not too long:-) that explains the consequences of
that?