Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005 



In summary, I don't think this document is ready for publication.

Major comment is that I find the IANA section inadequate. It seems to
be introducing a new namespace for IANA to take care of, but no rules
on how new values are allocated.  It seems to indicate that an RFC
number is needed in section 10.3, but I think this needs to be more
specific.  The text in other places of the document are not so
clear at what constitues a reason for allocating new bit flags, etc.,
so in the IANA section, I think there needs to be explicit text on the
the mechanisms for specifying and definting them.

Additionally, I had a lot of trouble actually parsing much of the document,
I am not going to site every single instance, but some examples are listed
below.  I think an editorial pass is needed to enhance the comprehensibility
of the text.

Minor comments
1) Way too much acronyms in the abstract ...	
2) Took me several reads to be able to parse the following text:

    .... Because of the nature of the TLV
    construction the object is flexible and allows the future definition
    of:
    - further bit flags if further, distinct uses are discovered
    - arbitrary options and attributes parameters carried as individual
      TLVs.

suggest:

    The new RSVP-TE message object is quite flexible, due to the use of the
    TLV format and allows:
    - future specification of bit flags
    - additional options and atttribute paramerters carried in TLV format.

"if further, distinct uses are discovered" and "arbitrary options and attributes"
sounds like an open invitation for folks to invent new things without good reason ...

3) This text was confusing:

 4.2 Generic Processing Rules for Path Messages

   An LSR that does not support this object will pass it on unaltered
   because of the C-Num.

suggest:

 4.2 Generic Processing Rules for Path Messages

   An LSR that does not support this object is required to pass it on unaltered,
   as the C-Num indicates that the LSR should pass the object on transparently.