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