Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol
RFC 3988
Yes
No Objection
No Record
Note: This ballot was opened for revision 03 and is now closed.
(Alex Zinin; former steering group member) Yes
(Bill Fenner; former steering group member) Yes
(Bert Wijnen; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
While I'm not sure that this cold be subject of a discuss, the level of jargon (unexpanded acronyms in particular) in this document makes it hard to understand.
(Russ Housley; former steering group member) No Objection
There are a lot of acronyms in the first two paragraphs of the Introduction that are not expanded. Please add a pointer to section 5 of [2] in the Security Considerations.
(Scott Hollenbeck; former steering group member) No Objection
The draft says it updates RFC 3036, which implies it should also be a Standards Track document and not Experimental as currently identified. Either that or the document should be changed to not update 3036.
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
Reviewed as a candidate for Experimental, since that was the category on the agenda; note that the document lists a category of Standards Track, and an RFC Editor note to clear that up is required.
(Thomas Narten; former steering group member) No Objection
carry MTU information for a FEC between adjacent LSRs in LDP Label expand/define FEC? Ditto for other terms on first use? E.g., TLV? > 2.4. MTU TLV surprised that there isn't a line here saying length is always 2 (or whatever it is, since its presumably fixed.) > Changes in MTU for sections of an LSP may cause intermediate LSRs to > generate unsolicited label Mapping messages to advertise the new MTU. > LSRs which do not support MTU signalling MUST accept these messages, > but MAY ignore them (see Section 2.1). > don't understand the reference to 2.1. Also wording is odd, saying an implementation that doesn't support this spec "MAY" ignore messages. Don't they kind of do that be definition? Certainly not an implementation decision in the MAY sense.
(Allison Mankin; former steering group member) No Record
The TCP spoofing attack and the remedy are way too tersely mentioned - it's impossible to understand how they fit in.