Skip to main content

LDP Capabilities
RFC 5561

Yes

(Ross Callon)

No Objection

(Alexey Melnikov)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Russ Housley)

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

Lars Eggert No Objection

Comment (2009-04-06)
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

Yes (2009-04-09)
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

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

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

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

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

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) (was Discuss) No Objection

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

No Objection ()