GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-13

I agree with Stephen on the nesting problem for the security considerations.  Since RFC6060 points out that a hostile environment should be assumed, it would be good to mention other security protections with the appropriate links directly in the security considerations section of this document.

I have only given this a quick look over and there is nothing here that bothers me from an applications area perspective.

I would suggest a good scrub of what may or may not (no pun intended) be interoperability requirements text. There are many "must"s that appear to be very much about interoperability requirements and many "MUST"s that appear to not be. They seem randomly sprinkled. A review seems in order.

- section 2, para 2: the meaning of "co-routed" wasn't
entirely clear to me, but I think that's probably ok if what
you mean is the DA from one is the SA from the other and
vice-versa.  If it means something else, (e.g. that packets
from DA to SA must traverse the same links as from SA to DA)
that would be worth saying, or it would be worth referring
to some document that defines co-routed more fully.

- Table 1: You don't say what "reserved" means, but asssume
it means "do not use"?

- section 2, last para: I wondered what "subset" you meant
for MIPs.

- 3.1: I was surprised that so much is left for local
config, in particular the CCM Interval - am I right that
if you have different intervals setup then one of the
MEPs will be constantly calling the LSP broken because
CCM messages/frames won't arrive on time? (Though I see
in 3.3.4 that you can send this info from one to the
other, but I don't see where it says what to do with
that value on receipt.)

- 3.3.x, I hope IANA notice they're being asking for
something (or you repeat it later)

- 3.3.3: what if received a MEP ID is >=8192? (e.g. 2^14)
(I also wondered why you want to save 3 bits but don't
just reserve them)

- 3.4: "PM" confused me briefly (cf. RFC7258:-)

- section 5: defers to [OAM-CONF-FWK] - which draft is that?
(I'm guessing
https://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk
right?) And to RFC6060 which defers to RFC4872 which
eventually says that "RSVP signaling MUST be able to provide
authentication and integrity" - does that latter apply here?
If so, (which I assume since that's a normative ref)
wouldn't it be nice to remove the double indirection and
just point that out directly.