Ben Campbell provided comments on -09 of this document based on his
  Gen-ART Review, and they have not been addressed.  The Gen-ART Last
  Call comments were mostly editorial, and all minor.  Since the
  comments are minor, I am not entering a DISCUSS, but it is really
  bad form to ignore Last Call comments.  Please be more respectful
  of reviewer time in the future.
  
  Since others have entered DISCUSS positions on this document,
  please consider these comments from Ben Campbell.
  
  
  Abstract:

  Please expand TLV and IS-IS on first use. Expanding OSPF would not
  hurt, but it is probably well-known enough not to require expansion.

  s/"statistical assumption"/"statistical assumptions"
  (should be plural.)


  Requirements Language:

  It's a bit odd to see this prior to the Table of Contents. I usually  
  see it in the terminology section. I don't know if it matters.


  Section 1:

  Most of the terms are just acronym expansions. It might be nice to put  
  in short definitions, unless all of the terms are sufficiently well-
  known not to need definitions.


  Section 2, paragraph 1:

  I find the heavy use of parentheses to detract from the flow of the  
  paragraph. Also, when nesting parentheses, please use other symbols.  
  For example ( ... [ ... { ... } ... ] ... ) instead of ( ... ( ...  
  ( ... ) ... ) ... )


  paragraph 2:

  s/"other metric"/"other metrics"
  (should be plural.)


  "Unfortunately,
  for instance in the presence of ECMPs (Equal Cost Multi-Paths) in
  symmetrical networks when unconstrained TE LSPs are used, such
  metrics (e.g. path cost, number of hops, ...) are usually ineffective
  and may lead to poorly load balanced traffic."

  I found this sentence hard to follow. Can it be simplified?


  paragraph 3:

  s/"statistical assumption"/"statistical assumptions"
  (should be plural.)

  Also, can you offer a sentence or two explaining what you mean by  
  "statistical assumptions"? I think I know what you mean, but I don't  
  think it will be obvious to all readers.


  paragraph 5:

  A comma would be a better choice than parentheses in this context.


  paragraph 7:

  Why is it okay to omit unconstrained TE LSPs that are provisioned?


  Section 3.1, definition of "Value"

  Is the encoding of the numeric value well-known for this context, or  
  should this document specify it?


  Section 3.2, definition of "Value"

  Is the encoding of the numeric value well-known for this context, or  
  should this document specify it?


  Section 4 , title:

  I'm not sure what the title means. I suggest "Procedures".


  paragraph 1:

  Is that intended to be a normative SHOULD?


  Section 5:

  The text said the type numbers were to be assigned by IANA, with 23  
  being a suggested value. That is not clear in the IANA considerations.


  Section 6:

  Can the information carried in this new parameter ever be sensitive,  
  or useful to an attacker? I'm not saying it is, but it might be useful  
  to mention this one way or another in the security considerations.