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.