LDP Capabilities
RFC 5561

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

(Jari Arkko) Yes

Comment (2009-04-09 for -)
No email
send info
The name of the U bit would have been nice to have in the doc.

I agree with the issues other people have raised.

(Ross Callon) Yes

(Ron Bonica) (was Discuss) No Objection

Comment (2009-04-07)
No email
send info
I think that this DISCUSS can be cleared up with an RFC editor note:

In Section 3, you should say that the U bit tells a LDP speaker how to behave if it does not support this capability (u stands for unsupported?)

In Section 3, why does the F-bit exist if it must always be set to 0? If it might be set to 1 at some future time, shouldn't you tell us what to do when that happens?

In Section 3.1, you might want to enumerate the exiting protocol extensions that could act as capability TLVs.

(Lisa Dusseault) No Objection

Comment (2009-04-07 for -)
No email
send info
The advice on future documents that actually name and define capabilities, seems to be incomplete.  Perhaps its clear to the authors, but I don't understand which IANA registry future capabilities would be listed in.  

It would also be good to advise those future capabilities defining documents, to specify whether the capability is even appropriate for being advertised mid-session.  Some capabilities might require dropping a session.

(Lars Eggert) No Objection

Comment (2009-04-06 for -)
No email
send info
Should this document update RFC5036; i.e., is this something that should be considered must-implement for LDP from now on?

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-04-02)
No email
send info
Since the intention is to publish an RFC that will be current, it would be advisable to remove present tense text from the Abstract that will actually refer to the past. Thus, suggest you delete...

 At present, LDP has no 
 mechanism for advertising such enhancements at LDP session 
 initialization time.  There is also no mechanism to enable and 
 disable enhancements after the session is established.

There is similar text in the Introduction that I would also recommend you to delete.


It would be wise to include a reference (informative) to draft-ietf-mpls-mpls-and-gmpls-security-framework in section 11

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Robert Sparks) No Objection

Magnus Westerlund No Objection