Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol
RFC 3988

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

(Bill Fenner) Yes

(Alex Zinin) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

Comment (2004-04-02 for -)
No email
send info
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.

(Ted Hardie) No Objection

Comment (2004-03-29 for -)
No email
send info
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.

(Scott Hollenbeck) No Objection

Comment (2004-03-30 for -)
No email
send info
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.

(Russ Housley) No Objection

Comment (2004-03-30 for -)
No email
send info
  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.

(David Kessens) No Objection

(Thomas Narten) No Objection

Comment (2004-04-02 for -)
No email
send info
  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.

(Bert Wijnen) No Objection

(Allison Mankin) No Record

Comment (2004-04-02 for -)
No email
send info
The TCP spoofing attack and the remedy are way too tersely mentioned -
it's impossible to understand how they fit in.