[spring] Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

[Deborah Brungard <[e-mail]>]

Deborah Brungard has entered the following ballot position for
draft-ietf-spring-oam-usecase-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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