Signaling LDP Label Advertisement Completion
Note: This ballot was opened for revision 04 and is now closed.
(Adrian Farrel) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Ralph Droms) No Objection
Comment (2009-08-08 for -** No value found for 'p.get_dochistory.rev' **)
Add "(no affiliation)" for Bob Thomas on the title page to avoid confusion with (possible) affiliation with Huawei?
(Lisa Dusseault) No Objection
(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...
(Pasi Eronen) No Objection
(Russ Housley) (was Discuss) No Objection
(Alexey Melnikov) No Objection
Comment (2009-08-03 for -** No value found for 'p.get_dochistory.rev' **)
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?
(Tim Polk) No Objection
(Dan Romascanu) No Objection
Comment (2009-08-10 for -** No value found for 'p.get_dochistory.rev' **)
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.