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

"Yemin (Amy)" <> Thu, 11 April 2019 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 230AC1200A3; Thu, 11 Apr 2019 03:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UESqQOloxk6S; Thu, 11 Apr 2019 03:21:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C86E12004D; Thu, 11 Apr 2019 03:21:01 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 52DBE92C43F8BC10842A; Thu, 11 Apr 2019 11:20:59 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:20:58 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:20:46 +0800
From: "Yemin (Amy)" <>
To: Alissa Cooper <>, Paul Kyzivat <>
CC: "" <>, "General Area Review Team" <>
Thread-Topic: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Thread-Index: AQHU5Yk31HWCp9UXpUyAzdBEenCTZKYqGvlQgAtLKACAAW70DQ==
Date: Thu, 11 Apr 2019 10:20:45 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Apr 2019 10:21:04 -0000

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

发件人: Alissa Cooper []
发送时间: 2019年4月11日 4:26
收件人: Yemin (Amy); Paul Kyzivat
抄送:; 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.


> On Apr 8, 2019, at 5:49 AM, Yemin (Amy) <> 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 []
> Sent: Friday, March 29, 2019 1:10 AM
> To:
> Cc: General Area Review Team <>
> 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 <​>.
> 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