Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

Thank you, Alissa.
We will change it to informative text. 

BR,
Amy
________________________________________
发件人: Alissa Cooper [alissa@cooperw.in]
发送时间: 2019年4月11日 4:26
收件人: Yemin (Amy); Paul Kyzivat
抄送: draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org; General Area Review Team
主题: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

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) <amy.yemin@huawei.com> 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:pkyzivat@alum.mit.edu]
> Sent: Friday, March 29, 2019 1:10 AM
> To: draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org
> Cc: General Area Review Team <gen-art@ietf.org>
> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art