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

[Ballot 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

[Ballot 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. The first sentence
of the abstract could be improved:
a path monitoring/s/an MPLS path monitoring

[Ballot comment]
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  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  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.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
The document describes both use cases and a standalone monitoring framework. The monitoring system re-uses existing IETF OAM protocols and leverage Segment Routing (Source Routing) to allow a single device to both sends and receives its own probing packets. As a consequence, there are no new interoperability considerations, Standard Track is not required and Informational status seems appropriate.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes features of a path monitoring system and
  related use cases.  Segment based routing enables a scalable and
  simple method to monitor data plane liveliness of the complete set of
  paths belonging to a single domain.  This MPLS monitoring system complements
  the traditional MPLS ping and LSP path trace.

Working Group Summary:

This document is present in the WG since its BOF and had no controversy.

Document Quality:

There is one prototype implementation which has been running in one research backbone. The resulting measurements have been compared to the results measured by three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents and the results are equivalents. This is documented in draft-leipnitz-spring-pms-implementation-report-00.

Personnel:

Bruno Decraene is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've read all related emails on the SPRING mailing list.
I've reviewed -04 and sent comments on the authors and the mailing list. https://mailarchive.ietf.org/arch/msg/spring/u0AS__6ZlKnhxQ_j7qJaiKIxvVw
Authors have addressed all those comments in -05 which resulted in significant editorial change in the document. I've reviewed -05 and sent additional comments. https://mailarchive.ietf.org/arch/msg/spring/P5FkKeKpnw7a62EsrKxdk_PRldw


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Reviews in the WG have been quite limited. However the implementation report (draft-leipnitz-spring-pms-implementation-report-00) is of good quality and show that significant work has been done behind the scene.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. A review from the MPLS WG may provide additional feedback, but on the other hand this document is informational and only using the MPLS OAM protocols with no modification. Plus the implementation report is already a good reality check.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Readability could possibly be further improved but the RFC editor will have the chance to make suggestions.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have replied to the IPR poll.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR have been filed: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-oam-usecase
Those IPR have been reminded during the WGLC and the WG did not comment on the IPR.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It represent the strong concurrence of a few individuals, with others being silent


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

All nits found in -04 and -05 have been addressed in -06.
ID-nits still reports the lack of Form Feed. The issue has been found (use of the unpaginated option in XML2RFC). Authors will fix this in the next revision.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

No IANA section. This is appropriate.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registry.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

N/A (no formal language)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
The document describes both use cases and a standalone monitoring framework. The monitoring system re-uses existing IETF OAM protocols and leverage Segment Routing (Source Routing) to allow a single device to both send and receives its own probing packets. As a consequence, there is no new interoperability considerations, Standard Track is not required and informational status seems appropriate.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes features of a path monitoring system and
  related use cases.  Segment based routing enables a scalable and
  simple method to monitor data plane liveliness of the complete set of
  paths belonging to a single domain.  This MPLS monitoring system complements
  the traditional MPLS ping and LSP path trace.

Working Group Summary:

This document is present in the WG since its BOF and had no controversy.

Document Quality:

There is one prototype implementation which has been running in one research backbone. The resulting measurements have been compared to the results measured by three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents and the results are equivalents. This is documented in draft-leipnitz-spring-pms-implementation-report-00.

Personnel:

Bruno Decraene is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've read all related emails on the SPRING mailing list.
I've reviewed -04 and sent comments on the authors and the mailing list. https://mailarchive.ietf.org/arch/msg/spring/u0AS__6ZlKnhxQ_j7qJaiKIxvVw
Authors have addressed all those comments in -05 which resulted in significant editorial change in the document. I've reviewed -05 and sent additional comments. https://mailarchive.ietf.org/arch/msg/spring/P5FkKeKpnw7a62EsrKxdk_PRldw


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Reviews in the WG have been quite limited. However the implementation report (draft-leipnitz-spring-pms-implementation-report-00) is of good quality and show that significant work has been done behind the scene.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. A review from the MPLS WG may provide additional feedback, but on the other hand this document is informational and only using the MPLS OAM protocols with no modification. Plus the implementation report is already a good reality check.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Readability could possibly be further improved but the RFC editor will have the chance to make suggestions.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have replied to the IPR poll.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR have been filed: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-oam-usecase
Those IPR have been reminded during the WGLC and the WG did not comment on the IPR.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It represent the strong concurrence of a few individuals, with others being silent


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

All nits found in -04 and -05 have been addressed in -06.
ID-nits still reports the lack of Form Feed. The issue has been found (use of the unpaginated option in XML2RFC). Authors will fix this in the next revision.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

No IANA section. This is appropriate.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registry.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

N/A (no formal language)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-oam-usecase-06.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: aretana@cisco.com, spring@ietf.org, spring-chairs@ietf.org, draft-ietf-spring-oam-usecase@ietf.org, bruno.decraene@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Scalable and Topology-Aware MPLS Dataplane Monitoring System) to Informational RFC


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'A Scalable and
Topology-Aware MPLS Dataplane Monitoring System'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes features of a path monitoring system and
  related use cases.  Segment based routing enables a scalable and
  simple method to monitor data plane liveliness of the complete set of
  paths belonging to a single domain.  The MPLS monitoring system adds
  features to the traditional MPLS ping and LSP path trace, in a very
  complementary way.  MPLS topology awareness reduces management and
  control plane involvement of OAM measurements while enabling new OAM
  features.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2314/
  https://datatracker.ietf.org/ipr/2406/

=== AD Review of draft-ietf-spring-oam-usecase-06 ===

I just finished reading this document.  Thank you for using a more descriptive name for this document.

I have some comments (please see below) that I would like to see addressed before putting this document up for review by the IESG.  I am however starting the IETF Last Call with the understanding that my comments (and any other received) will be addressed together.

Thanks!

Alvaro.


Major:

M1. The Introduction says that the monitoring system described in this document will be simplified “by enabling MPLS topology detection based on IGP signaled segments as specified by [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-idr-bgp-ls-segment-routing-ext]… This topology awareness can be used for OAM purposes as described by this document.”  This sounds as if those extensions are critical to the monitoring system; IOW, Normative.  However, the extensions are not mentioned in the document anymore, so I would think that the concept is what is important here, right?  In lieu of making the references Normative, please consider simply generically referring to topology awareness in the Introduction (as you do elsewhere) and take the references out.


M2. Section 12. (Security Considerations).  This section seems to be just a random collection of thoughts, and not a well thought out description of potential threats and possible mitigation.  Please take a look at rfc3552.  I have some specific comments:

609        12.  Security Considerations

611            As mentioned in the introduction, a PMS monitoring packet should
612            never leave the domain where it originated.

What is the risk?  How can it be mitigated?

612                                                                                                It therefore should
613            never use stale MPLS or IGP routing information.

I’m not sure if you mean that using stale information leads to leaking, or if not using it can prevent it.  In either case, how can the PMS (or transit LSRs) recognize and prevent its use?

613                                                                                          Further, assigning
614            different label ranges for different purposes may be useful.  A well
615            known global service level range may be excluded for utilisation
616            within PMS measurement packets.

Now you seem to be talking about isolation of the management traffic.  Again, what are we avoiding here?  I note that the text only says that this “may be useful”, so there are probably cases where it isn’t necessary – when, why?


616                                                                            These ideas shouldn't start a
617            discussion.  They rather should point out, that such a discussion is
618            required when SR based OAM mechanisms like a SR are standardised.

“shouldn’t start a discussion…[but] such a discussion is required…”  Hmmm…

“SR based OAM mechanisms like a SR” -- ??

It sounds like you’re trying to say that OAM mechanisms should consider something, what?  Domain boundaries? Stale information? Isolation?

I am a little confused, but this document “describes a system using MPLS data plane path monitoring capabilities” using SR – which I thought meant that no new SR based OAM mechanisms are to be standardized.  Section 10 talks about potential extensions that are not part of what is presented here… What did I miss?

620            Should the approach of a PMS connected to an SR domain by a tunnel be
621            picked up, some fundamental MPLS security properties need to be
622            discussed.

Picked up…??  Do you mean used, implemented, ??

What “fundamental MPLS security properties” are you referring to?  Because you are describing approach here, this document is the place to at least mention those “fundamental MPLS security properties”.

622                                      MPLS domains so far allow to separate the MPLS network
623            from an IP network by allowing no tunneled MPLS access to an MPLS
624            domain.

This does seem like a potential security issue.  What are the risks? How can they be mitigated?



M3. References

- RFC4379 was obsoleted by RFC8029.  Please update the references and check to make sure they are still valid.
- I-D.ietf-spring-segment-routing should be Normative.



Minor:

P1. Consider merging the Acronyms and Terminology sections – or at least putting both of them after the Introduction.  I know that this would mean that some acronyms would have to be expanded in the Introduction.

P2. “BFD or LSP Ping format”…references?

P3. The reference to I-D.ietf-spring-sr-oam-requirement seems superfluous to me as there is no analysis to confirm that the requirements are met or even in line with the use cases presented – nor do I think there’s a need for that.

P4. Terminology

P4.1. The definition of Continuity Check is copied exactly from rfc7276 – and there seems to be no special meaning when related to segment routing.  Suggestion: just include a statement that the terminology in rfc7276 is used.

P4.2. The definition of Connectivity Verification taken from rfc7276 doesn’t match what that RFC says; instead, it looks like the definition included here is a summary/interpretation.  Suggestion: again, just reference rfc7276 as a whole – this will avoid definitions that don’t match.

P4.3. “RFC 4379 [RFC4379] specifies a Connectivity Verification for MPLS domains.”

P4.3.1. RFC4379 has been obsoleted by RFC8029.

P4.3.2. I tried looking at those RFCs to figure out what was the purpose this seemingly random sentence is, knowing that the concepts from rfc7276 are the dominant ones, but couldn’t.  Please consider rewriting or removing.

P4.3.3. Related –  Section 5.1 says: “…should support RFC 4379 and its standardised extensions.”  RFC4379 was updated by several RFCs, but RFC8029 isn’t.  Does that change this phrase?  Do you need to specifically point at which extensions are needed?


P5. In 5.3: “Such a design is not within scope of this document.”  What design?  I guess you mean going through the details for those cases.  If so, then we can get rid of this sentence.


P6.  Section 7:

“In the above example…”  You mean the one illustrated in Figure 1, right?

“three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents”  Please reference the agents explicitly – no need to mention the WG.

s/statistical test published by the IPPM WG[RFC6576]/statistical test in [RFC6576]



P7. Section 9 (Connectivity Verification Using PMS).  Section 3 already says that “This document proposes the use of SR based network monitoring as a new Continuity Check method.  In some special cases, it also covers some limited Connectivity Verification.  When applicable, this is indicated in the description of the use case.”  So it seems to me that this Section is not needed.  The text doesn’t seem to provide anything more beyond that statement.

P8.  Section 10. (Extensions of Specifications Relevant to this Use Case) also doesn’t seem to say much, specially because rfc4379 has already been obsoleted…



Nits:

N1. “pre Segment Routing” is used in several places, seemingly interchangeably with “non segment routing”.  Please be consistent.  Personally, I prefer “non segment routing”.

N2. s/as specified by specified by/as specified by

N3. I find that the Introduction reads in parts like a marketing brochure.  It would be ideal if you could reword and focus…

N4. s/by RFC4379 (using the Downstream (Detailed) Mapping information resulting from a "tree trace", see [RFC4379]/by RFC4379 (using the Downstream (Detailed) Mapping information resulting from a "tree trace"    Don’t need the second reference.

N5. s/T-LDP/tLDP
The RFC Editor’s abbreviation list uses it that way.  [https://www.rfc-editor.org/materials/abbrev.expansion.txt]

N6. s/Obviously/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
This is appropriate for a document describing use cases and one standalone monitoring system using existing IETF protocols.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes features of a path monitoring system and
  related use cases.  Segment based routing enables a scalable and
  simple method to monitor data plane liveliness of the complete set of
  paths belonging to a single domain.  This MPLS monitoring system complements
  the traditional MPLS ping and LSP path trace.

Working Group Summary:

This document is present in the WG since its BOF and had no controversy.

Document Quality:

There is one prototype implementation which has been running in one research backbone. The resulting measurements have been compared to the results measured by three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents and the results are equivalents. This is documented in draft-leipnitz-spring-pms-implementation-report-00.

Personnel:

Bruno Decraene is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've read all related emails on the SPRING mailing list.
I've reviewed -04 and sent comments on the authors and the mailing list. https://mailarchive.ietf.org/arch/msg/spring/u0AS__6ZlKnhxQ_j7qJaiKIxvVw
Authors have addressed all those comments in -05 which resulted in significant editorial change in the document. I've reviewed -05 and sent additional comments. https://mailarchive.ietf.org/arch/msg/spring/P5FkKeKpnw7a62EsrKxdk_PRldw


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Reviews in the WG have been quite limited. However the implementation report (draft-leipnitz-spring-pms-implementation-report-00) is of good quality and show that significant work has been done behind the scene.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. A review from the MPLS WG may provide additional feedback, but on the other hand this document is informational and only using the MPLS OAM protocols with no modification. Plus the implementation report is already a good reality check.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Readability could possibly be further improved but the RFC editor will have the chance to make suggestions.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have replied to the IPR poll.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR have been filed: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-oam-usecase
Those IPR have been reminded during the WGLC and the WG did not comment on the IPR.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It represent the strong concurrence of a few individuals, with others being silent


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

All nits found in -04 and -05 have been addressed in -06.
ID-nits still reports the lack of Form Feed. The issue has been found (use of the unpaginated option in XML2RFC). Authors will fix this in the next revision.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

No IANA section. This is appropriate.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registry.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

N/A (no formal language)