Skip to main content

Signaling LDP Label Advertisement Completion
RFC 5919

Yes

(Adrian Farrel)

No Objection

(Jari Arkko)
(Lisa Dusseault)
(Pasi Eronen)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Lars Eggert (was Discuss, No Objection) No Objection

Comment (2009-08-11)
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

Yes ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2009-08-03)
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

No Objection (2009-08-10)
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

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2009-08-08)
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

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection ()