Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping
RFC 7759
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
Alvaro Retana No Objection
(Deborah Brungard; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
I have one minor (almost trivial) comment/question, and several nits: Comment: ========= - 4.1, paragraph 3: Is it reasonable for a TLV in this standards-action registry to be have sub-tlvs with reduced registration requirements? (And if so, is there a reason to exclude specifications that are not RFCs?) Nits: ==== -1, paragraph 1: Missing "the" before "MPLS Transport Profile " - 1.0, last paragraph, last two sentences: Who are “we” in these sentences? Does it make sense to talk about what “we” are or are not “configuring”? 2.1.1, first bullet in first list: consider s/"both sides should be"/"both sides are" -4.1, 2nd paragraph, first sentence: Missing words? (What is IANA requested to do with the TLV? I assume register it. Also, what is the name of the new TLV? Consider a cross-reference to table to for "this sub-registry" -4.2: "Assignments of bit positions 0 through 31" If I read correctly, that's all the bits. Is this the same as saying the registry itself requires standards-action? -5: It's mildly odd to find the acknowledgements section between two substantive sections. -6, first paragraph: Should "liveliness" be "liveness"?
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Mehmet Ersue performed the opsdir review.
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 2.1.1, is there any chance of moving on from the "Keyed SHA1" from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to get that kind of transition done as we can and moving to use of a standard integrity check rather than a more home-grown one has some benefits. The HMAC-SHA1-like thing you're doing is still probably ok, (though could maybe do with crypto eyeballs on it as there may have been relevant new results since 2010) but future-proofing would suggest moving to HMAC-SHA256 if we can. (I can imagine such a change might require a new document, but am asking anyway:-) - 2.1.1, I'd recommend saying any password auth-type MUST NOT be used - would that be possible? - section 6 - what "established secure key-exchange protocol" is available to use here? - (this is sort of off-topic) I find an architecture like this where a packet traversing a network has quite so many side-effects a bit hard to grok. Do you have a pointer to something (not too long:-) that explains the consequences of that?
(Terry Manderson; former steering group member) No Objection