Paul, thanks for your review. Amy, thanks for your response. Benjamin filed a DISCUSS on this point, which I support. I think based on the text you quote from RFC 2205, normative language to describe the error handling here is not appropriate. I entered a No Objection ballot in support of his DISCUSS.
Alissa > On Apr 8, 2019, at 5:49 AM, Yemin (Amy) <[email protected]> wrote: > > Hi Paul, > > In 3.10 of RFC2205, e.g., Unknown C-Type for Known Class, > "Generally, the appearance of an object with unknown C-Type should result in > rejection of the entire message and generation of an error message (ResvErr > or PathErr as appropriate)." > It use "should" but in lower case. > > In additional to RFC2205, RFC5711 defines "Node Behavior upon Originating and > Receiving Resource Reservation Protocol (RSVP) Path Error Messages". > In section 2.1 of RFC5711, > "In the case of fatal errors ("Hard Preemption"; see Section 4.7.3 of > [RFC3209] ), the detecting node MUST send a PathErr message reporting the > error condition, .... > In the case of non-fatal errors, the detecting node should send a PathErr > message, and must not clear control plane or data plane state. " > > Considering the case in this draft, such error can be considered as non-fatal > error (the path can still be set up disregarding the Availability TLV), thus > SHOULD is more appropriate here. > > BR, > Amy > -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: Friday, March 29, 2019 1:10 AM > To: [email protected] > Cc: General Area Review Team <[email protected]> > Subject: Gen-ART Telechat review of > draft-ietf-ccamp-rsvp-te-bandwidth-availability-14 > > 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. > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
