Signaling LDP Label Advertisement Completion
RFC 5919
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert (was Discuss, No Objection) No Objection
INTRODUCTION, paragraph 4: > LDP End-of-LIB Please expand all acronyms on first use. Section 0, paragraph 3: > U and F bits: Should be set 1 and 0 respectively as per section 4 > of LDP Capabilities [LDPCap]. s/Should/MUST/ or else explain when it is OK to not set these bits as described in [LDPCap] Section 0, paragraph 5: > S-bit: Must be 1 (indicates that capability is being advertised). s/Must/MUST/ Section 5., paragraph 1: > determination is a judgement call the LDP speaker makes. The Nit: s/judgement/judgment/ Section 9.1., paragraph 4: > [TypedWC] Thomas, B., Minei, I., "LDP Typed Wildcard FEC", draft- > ietf-mpls-ldp-typed-wildcard-03, Work in Progress, March > 2008. Expired since September 2008...
(Adrian Farrel; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
In Section 5.4; To deal with the possibility of missing notifications, an LDP speaker may time out receipt of an expected End-of-LIB Notification, and if the timeout occurs, it may behave as if it had received the notification. If the End-of-LIB Notification message is received after the time-out occurs, then the message should be ignored. s/should/SHOULD ? draft-ietf-mpls-ldp-capabilities was published as an RFC. What is the status of ietf-mpls-ldp-typed-wildcard?
(Dan Romascanu; former steering group member) No Objection
This is a relatively concise and well-written specification. I beieve that the following editorial improvements would add to clarity. 1. 'End-of-LIB' is mentioned in the title, but this being the name of the message and not a very self-explaining one people may have problems in understanding what the specification is about. Replacing with something more explicit, or detailing in the abstract that 'End-ofLIB' is the name of the message would help. 2. Acronyms like FEC or TLV should be expanded at first occurance. 3. Section 5 is non-normative, including implementation and behavior guidelines. The exception is 5.4 which includes a mandatory behavior requirement without which interoperability is not possible. I would suggest moving 5.4 to section 4 - as this is note than a 'guideline' item.
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
Add "(no affiliation)" for Bob Thomas on the title page to avoid confusion with (possible) affiliation with Huawei?
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) No Objection