Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
"Yemin (Amy)" <amy.yemin@huawei.com> Thu, 11 April 2019 10:21 UTC
Return-Path: <amy.yemin@huawei.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230AC1200A3; Thu, 11 Apr 2019 03:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UESqQOloxk6S; Thu, 11 Apr 2019 03:21:01 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C86E12004D; Thu, 11 Apr 2019 03:21:01 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 52DBE92C43F8BC10842A; Thu, 11 Apr 2019 11:20:59 +0100 (IST)
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:20:58 +0100
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.72]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:20:46 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Alissa Cooper <alissa@cooperw.in>, Paul Kyzivat <pkyzivat@alum.mit.edu>
CC: "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
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: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC095@DGGEMM528-MBX.china.huawei.com>
References: <b56bca60-c107-39c2-8cb7-5aede95731e4@alum.mit.edu> <9C5FD3EFA72E1740A3D41BADDE0B461FCFBD675A@DGGEMM528-MBX.china.huawei.com>, <2CA1EEFD-D086-4900-A01C-9C3524275068@cooperw.in>
In-Reply-To: <2CA1EEFD-D086-4900-A01C-9C3524275068@cooperw.in>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.156]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/tqxLLthjVzirrm8X_tStGltKD48>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 10:21:04 -0000
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
- [Gen-art] Gen-ART Telechat review of draft-ietf-c… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Yemin (Amy)
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Alissa Cooper
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Yemin (Amy)