Re: [CCAMP] Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

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

Hi Alexey,

Thanks for the comments. 
Benjamin also rasied the same comments, we will change the MAY to MUST. 

BR,
Amy
________________________________________
发件人: Alexey Melnikov via Datatracker [[e-mail]]
发送时间: 2019年4月11日 16:14
收件人: The IESG
抄送: [e-mail]; Daniele Ceccarelli; [e-mail]; [e-mail]; [e-mail]
主题: Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: 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-rsvp-te-bandwidth-availability/



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

Thank you for a well written document.

I have a few easy to address comments.

Other people already commented on the lack of reference for the float format.

In the following text:

   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]).
   When a node receives Availability TLVs which mixed of zero index and
   non-zero index, the message MAY be ignored and SHOULD NOT be

What does “MAY ignore” mean here and what are the implications of not ignoring?
I tend to think that this shoukd be MUST for interoperability, so either
changing this to MUST or adding explanatory text for MAY would address my
concern.

   propagated. When a node receives Availability TLVs (non-zero index)
   with no matching index value among the bandwidth-TLVs, the message
   MAY be ignored and SHOULD NOT be propagated. When a node receives

Same comment as above.

   several <bandwidth, availability> pairs, but there're are extra
   bandwidth-TLVs without matching index Availability-TLV, the extra
   bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated.