Telechat Review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
review-ietf-ccamp-rsvp-te-bandwidth-availability-14-genart-telechat-kyzivat-2019-03-28-00

Request Review of draft-ietf-ccamp-rsvp-te-bandwidth-availability
Requested revision No specific revision (document currently at 16)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-04-09
Requested 2019-03-20
Authors Hao Long , Min Ye , Greg Mirsky , Alessandro D'Alessandro , Himanshu C. Shah
I-D last updated 2019-03-28
Completed reviews Rtgdir Last Call review of -11 by Matthew Bocci (diff)
Genart Last Call review of -13 by Paul Kyzivat (diff)
Secdir Last Call review of -13 by Sandra L. Murphy (diff)
Secdir Telechat review of -14 by Sandra L. Murphy (diff)
Genart Telechat review of -14 by Paul Kyzivat (diff)
Opsdir Telechat review of -14 by Shwetha Bhandari (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Telechat review on draft-ietf-ccamp-rsvp-te-bandwidth-availability by General Area Review Team (Gen-ART) Assigned
Reviewed revision 14 (document currently at 16)
Result Ready w/issues
Completed 2019-03-28
review-ietf-ccamp-rsvp-te-bandwidth-availability-14-genart-telechat-kyzivat-2019-03-28-00
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.