Requirements for Hitless MPLS Path Segment Monitoring
RFC 8256

Note: This ballot was opened for revision 13 and is now closed.

Deborah Brungard Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2017-03-22 for -13)
No email
send info
Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is wrong, or that the working group has knowingly chosen a particular path, or that some clarification or changes are needed in the document. But substantial comments need to be addressed in some fashion, and I don't feel we're quite there yet. But I also didn't see much discussion on my e-mail search, it is possible of course that discussion happened without me seeing it (I'm not on the MPLS WG list).

All that being said, I held a Discuss position as a request for discussion, but I did not plan to hold on to it beyond the initial telechat, and I have now cleared (also considering that I'm off the IESG in a couple of days).

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2017-03-15 for -13)
No email
send info
OPS DIR review from Jon Mitchell:

Document is Ready with Nits.  I share the concern that it's not
totally clear upfront this is
a requirements versus solution document.  There is also not much in
the way of requirements
of notification or how to signal back to the operator that a fault has
occurred, but this
may be OK if whatever solution would meet the requirements of this
draft will include
such text or rely on existing mechanisms discussed in RFC6371.

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Mirja Kühlewind No Objection

Comment (2017-03-14 for -13)
No email
send info
I don't see a value in publishing this document in the RFC series. Btw. the shepherd write up still says this doc is standards track.

Minor comments:
- The classification into M(andatory) and O(ptional) is not consistent with the use of MUST and SHOULD.
- The first sentence in the intro should use a lower case 'must'.
- Sections 2.2 and 5. could be removed.

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

(Alia Atlas) Abstain

Comment (2017-03-15 for -13)
No email
send info
I do not see the value of this document as an RFC - particularly absent any work on a solution
after 5 years.

Suresh Krishnan Abstain

Comment (2017-03-16 for -13)
No email
send info
Abstain for same reason as Alia.