Re: [CCAMP] Adam Roach's Discuss on draft-ietf-ccamp-ospf-availability-extension-10: (with DISCUSS and COMMENT)

["Yemin (Amy)" <[e-mail]>]

Hi Adam,

Thanks for your review. 
Regarding the discuss item, how about to remove " The registration procedure for this registry is Standards Action as defined in [RFC8126]."
For the rest comments, we will address in next version. 

BR,
Amy
-----Original Message-----
From: Adam Roach [mailto:[e-mail]] 
Sent: Wednesday, October 11, 2017 8:48 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Fatai Zhang <[e-mail]>; [e-mail]; Fatai Zhang <[e-mail]>; [e-mail]
Subject: Adam Roach's Discuss on draft-ietf-ccamp-ospf-availability-extension-10: (with DISCUSS and COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-ccamp-ospf-availability-extension-10: 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-ospf-availability-extension/



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

draft-ietf-teas-gmpls-scsi creates an IANA table "Generalized SCSI (Switching Capability Specific Information) TLVs Types" with a registration policy of "Specification Required."

This document adds a value to this registry, and goes on to claim:

   The registration procedure for this registry is Standards Action as
   defined in [RFC8126].

"Standards Action" is not the same as "Specification Required."

Since *this* document is not defining the registry, it should not reiterate the policy -- in particular because the policy can get out of sync if specified in multiple locations, as in this case.


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

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." -- and, of course, add a citation for IEEE 754-2008 to the normative reference section.

Additionally, while recipient behavior is described for the error of sending multiple TLVs with the same availability (yay!), I think you also want text around handling of TLVs that contain unexpected values (e.g., Availability >= 1.0, and handling of values like INF, -INF, and NaN). Options would include ignoring the TLV, or rejecting the entire ICSD. I'm not sure which is more consistent with typical OSCF handling.

The reference for [GSCSI] is out of date. This is complicated by the fact that the title doesn't match, so finding the correct document is quite difficult.
Please update to use "I-D.ietf-teas-gmpls-scsi-04" or something similar.

The IANA section is pretty confusing at the moment, as it claims "IANA has created...", even though the table in question is requested by draft-ietf-teas-gmpls-scsi. It's probably worth adding a note (with a "remove before publication") indicating that the registry will be created by draft-ietf-teas-gmpls-scsi, and that the requested value should be added to it when it is created.

____

Nits:

Please expand "TE" in the title.

Section 3.1:
   Type: 0x01, 16 bits.

As this is 16 bits, I recommend changing to: "0x0001, 16 bits"