I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: 2019-04-09

Summary:

This draft is on the right track but has open issues, described in the 
review.

Issues:

Major: 0
Minor: 1
Nits:  0

1) MINOR (maybe MAJOR):

Section 3.2 includes the following:

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

This seems to be placing a normative requirement on implementations of 
RSVP that *don't* support this document. That is clearly impossible.

I am guessing that this is the standard normative behavior for 
implementations of RSVP that encounter a TLV type they don't understand. 
(I tried to find this in RFC2205 but failed.) If so, then this section 
should be reworded to indicate that this is the behavior that will occur 
rather than a new normative requirement.

OTOH, if this is not the standard handling for unknown TLV types then 
you need to rethink this.