Signaling LDP Label Advertisement Completion
RFC 5919

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' **)
No email
send info
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

Comment (2009-08-11)
No email
send info
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).


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' **)
No email
send info
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' **)
No email
send info
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.

(Robert Sparks) (was Discuss) No Objection