[CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-ccamp-ospf-availability-extension-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(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.