Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping
RFC 7759

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

Alvaro Retana No Objection

(Deborah Brungard; former steering group member) Yes

Yes ( for -14)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2015-11-16 for -15)
No email
send info
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

No Objection ( for -15)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-11-18 for -15)
No email
send info
Mehmet Ersue performed the opsdir review.

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-11-18 for -15)
No email
send info
- 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

No Objection ( for -15)
No email
send info