LDP Capabilities
draft-ietf-mpls-ldp-capabilities-04

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

Should this document update RFC5036; i.e., is this something that should be considered must-implement for LDP from now on?

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.

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.