Document Title:  Extensions to OSPF for Advertising Optional Router Capabilities
Document: draft-ietf-ospf-cap-09.txt
Reviewer: David L. Black
Review Date: October 29, 2006
IETF LC Date: Ends November 6, 2006

Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:
This draft describes a small addition of bits to advertise
optional capabilities to OSPF.  All of the items in this
review are editorial in nature.

Section 3 - The use of "MUST" in the following sentence is not
appropriate, as this is a design requirement, not a protocol
requirement:

   Hence, discretion
   and sound engineering judgment MUST be adhered to when deciding
   whether newly proposed TLV(s) in support of a new application are
   advertised in the RI LSA or warrant the creation of an application
   specific LSA.

A lower case "must" would suffice, but a rephrasing to emphasize the
importance of this design concern in work on such TLVs would be better.

Section 4: The security considerations statement that this document
does not create any new security issues for the OSPF protocol is
too narrow.  The advertisement of capabilities may provide useful
information to an attacker looking for a particular feature or
vulnerability to attack.  No new OSPF security countermeasures
should be necessary, and it may be ok to refer discussion of this
issue to the existing OSPF RFCs if it is adequately covered there,
but the statement that there are no security considerations in the
functional content of this draft is not correct.

Section 5: Please tell IANA what the content of an entry is in
each of the new registries - saying that their fields are the
same as an existing registry is among the ways to do this.