OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth
draft-ietf-ccamp-ospf-availability-extension-13

Thank you for addressing my discuss and most of my comments. I'll note that the following comment applied to two fields ("Availability level" and "LSP Bandwidth at Availability level n"), while the fix has only been applied to "Availability Level":

> Section 3.1 defines two fields as being "32-bit IEEE floaing point", which
> runs the risk of becoming ambiguous in the future (e.g., while no 32-bit
> decimal representations are currently defined, IEEE did define new, smaller
> formats in the most recent revision of IEEE 754). Additionally, byte ordering
> is important here. Recommend changing as:
> 
> "This field is a binary32-format floating point number as defined by
> [IEEE754-2008]. The bytes are transmitted in network order; that is, the byte
> containing the sign bit is transmitted first."

This document should list the document that defines 32-bit IEEE floating point number as a Normative Reference, as it is required to implement the draft.

(1) Please include draft file names in the references, not just abbreviations.  That will make it easier to track the relationship and dependencies.  For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft (draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere.  Also, the “References” and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A].

[A] https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/references/ 


(2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).”  I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may


(3) Also from 3.2: 

   The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching
   Capability field values that have not been defined to support the
   Availability SCSI-TLV. Non-supporting nodes would see such as a
   malformed ISCD/LSA.

Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?


(4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  But that is not true!  Even if out of scope of this document, the intent has already been established that the information can be used for route computation.  I think you should then expand on the impact that tampering/changing the LSAs could have.

 I support Adam's DISCUSS.

It seems odd to find the terminology section before section 1.  Also, please consider using the boilerplate from 8174, especially since there are lower case instances of at least "should".

I think the reference to RFC5920 needs to be normative, since reading that document seems necessary to understand the security considerations.

This could lead to random outcomes
"If multiple are present, only the first Availability 
   SCSI-TLV for an availability level carried in the same ISCD SHALL be 
   processed. "
I would suggest the following instead:
"If multiple are present, the Availability 
   SCSI-TLV with the lowest bandwidth value SHALL be 
   processed. "

Nit: 
In section 3.1 you may actually specify the actual length value as done for the type:
OLD
"Length: A 16 bits field that expresses the length of the TLV in 
   bytes. "
NEW
"Length: 4 (bytes), 16 bits."