LDP Capabilities
RFC 5561
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
Should this document update RFC5036; i.e., is this something that should be considered must-implement for LDP from now on?
(Jari Arkko; former steering group member) Yes
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; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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
(Alexey Melnikov; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
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.
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) (was Discuss) No Objection
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.
(Russ Housley; former steering group member) No Objection