[CCAMP] Adam Roach's Discuss on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with DISCUSS and COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: Discuss

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-rsvp-te-bandwidth-availability/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for everyone's work on this document.

§3.1:

>     Availability (4 octets): a 32-bit floating point number describes
>     the decimal value of availability requirement for this bandwidth
>     request. The value MUST be less than 1and is usually expressed in
>     the value of 0.99/0.999/0.9999/0.99999.

"32-bit floating point number" is not sufficiently precise to specify the
encoding of this field. Presumably, this is intended to use IEEE 754-2008
32-bit binary interchange format. Please specify this, and add a normative
citation for IEEE 754-2008.


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

§3.2:

>  When a node does not support the Availability TLV, the node SHOULD
>  generate a PathErr message with the error code "Extended Class-Type
>  Error" and the error value "Class-Type mismatch" (see [RFC2205]).

Presumably, this "SHOULD" is a restatement of behavior defined in RFC 2205? (I
presume this because there's no way for this specification to retroactively
impose requirements on implementations that don't support it.) If so, please
remove the RFC-2119 language (or include it only as a direct quote from the RFC
that defines the requirement in the first place).