A Scalable and Topology-Aware MPLS Data-Plane Monitoring System
draft-ietf-spring-oam-usecase-10

Substantive Comments:

- General: I note there has been discussion about why this draft is Informational rather than something else. There's an explanation in the shepherd's writeup. It would be helpful to have the same explanation as a note in the draft. (People rarely read the shepherd's report once an RFC is published.)  

- 3, last paragraph: " Further options, like deployment of a PMS connecting to the MPLS domain by a tunnel only require more thought, as this implies security aspects."
I have trouble parsing that. Is it intended as an open issue, or a statement that the "further options" are out of scope?
Also, consider deleting the word "only".

-4.1, 2nd to last paragraph:
I'm not sure what to make of the "In theory at least," prefix. Normally IETF RFCs are about what (we hope) works in _practice_.

-10, last paragraph: I don't understand the intent of this paragraph.

Editorial Comments and Nits:
- section1, first sentence: s/operator/operators
- same section, first bullet: "operators" is repeated twice. (i.e. "operators operators")
-- third bullet: "allows to transport" should be either "allows <something> to transport" or "allows the transport". 
-- 4th bullet, last sentence: I suggest the following:
OLD:
[...] since both sender and receiver have the same clock, sequence numbers to ease the measurement...).
NEW:
[...] since both sender and receiver have the same clock and sequence numbers to ease the measurement.).

-10, 2nd paragraph: " The PMS allows to insert "
That should either be "allows <something> to insert" or "Allows the insertion"
-- 3rd paragraph: I can't parse the sentence. Should "avoid a PMS to insert traffic" be "prevent a PMS from inserting traffic"?
-- 4th paragraph: s/personal/personnel
-- 5th paragraph: I can't parse the last sentence.
-- 6th paragraph: "As soon as the PMS has an indication, that its IGP or MPLS topology are stale..."
The comma between "indication" and "that" should be removed.

Substantive Comments:
General:
I consider Informational status as appropriate. I found the draft title "oam-usecase"
a bit misleading as the document is specifically about a centralized OAM system,
but the document title is accurate so I'm ok as the draft title will not be visible once
an RFC. "Framework and use cases" would of been more appropriate (to me).

Because of the draft title, I found the document a bit confusing initially as I was not sure
if "system" was used in the BFD sense e.g. a functional component or as hinted at initially,
and as Section 4, Fig. 1 shows, a physically separate "system". Suggest it would help the
reader to more clearly say this in the Abstract (the rtgdir reviewer also hinted at this).

I'm not sure why the choice was to specifically specify a physically separate system? Why
not as a functional component with a use case as being physically separate? And considering
the document is scoped to a physically separate system, there is not much information
on what is needed to support a physical separation (other AD comments). I'd suggest
strongly to do a simple rewording to scope as a functional component. SDN architectures
are based on functional components as everyone has different ideas on the physical location
of a component and "functional" provides a flexibility. Suggest looking at RFC5623 on the
VNTM component.

Nits:
I found multiple sentences lacked clarity/grammar. Ben noted several. Will depend if
restructure to not preclude as a functional component. The first sentence
of the abstract could be improved:
a path monitoring/s/an MPLS path monitoring

Thanks for expanding the Security Considerations section per the SecDir review.
https://mailarchive.ietf.org/arch/msg/secdir/gV1oa_6mvzttXerCGeGnwSb905I