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

Alissa Cooper <alissa@cooperw.in> Wed, 10 April 2019 20:26 UTC

Return-Path: <alissa@cooperw.in>
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 6D07F120165; Wed, 10 Apr 2019 13:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=oc0yOXv9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=owSodzNf
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 Y8QLysOmhaN5; Wed, 10 Apr 2019 13:26:27 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60101200C3; Wed, 10 Apr 2019 13:26:26 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 22A1021C08; Wed, 10 Apr 2019 16:26:26 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 16:26:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m +gHE1ttMZtNzPX8Lss5LnYkhXZtoQsAFvaoV53kUrA=; b=oc0yOXv9XM3ZSqxdG 7p7fssrnJvGLd3ELV0lNrcs2g0GFiBLB71zuXgSp+4zzrjAR1308qnXQ2Jrz1qtr hGrqSwJkwlHGgYcfDdLCxkaJzlMevqtt3fyXUa9ZqMY49lC7mgbIwOaDTClAMUB3 nDRqu3/sv200C6ICOc1wprIjA0MCu/XHSbhxHVMnypJTHYMu9HPJHDwuqZC603Un IepDuhDxl4wR+F/TUVT6SvU6XWJyNn9511/qaeKZwpBOhPXoAKdYmSSWDCRkj0IJ 4sl+6DTCIYy248uuCVJ5XikvxjxChsL6LzGD/vkFkPM0+MAPtJYgbuRZagZzCp2C GZiNQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=m+gHE1ttMZtNzPX8Lss5LnYkhXZtoQsAFvaoV53kU rA=; b=owSodzNfEqaiAlUDtIN2koERLM9dJ11EQZdOgXDLOCv2WBqc1Z3KJmOkP ZkBLH2B3MNaodZrQhsPvaacmByHs8fwgEUlbGY+GfR/Il5NW+/aaI2aNjQX/bLr/ rZI7ynxdTG6fgjp8zm7VGgKm1uwIB9hVPsm7hw0dICCRocCnczpAZEeNIyvmf393 GL0dPzX3DWEZNzhnxf81kbn10Cv7dsjiup1uDqKQxHo6scFXLOFbZuqrew+MrXC7 MGQzAecrBq3CMD21MSVBt373rDtOjxr6ZMgeIju6McPOnsY2jVd6hSmBtuVD/lWf LTeq5BywAPJ8ApIg/4OBECz7rm74A==
X-ME-Sender: <xms:cVGuXHTFp6SzVQCwMNPwlxZu0Avl-UTOOf3X-o6QcwiOy0gKkx6nHw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdduheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:cVGuXEnSFooLjFGO6hBl9TJd1JW62iAuHyM2ZPexZydaIfSFeW5kOg> <xmx:cVGuXCVdd1XPnfpzx-yrz9kbLj1tivkOhgVl8tIB6PUXaiZUyT3zKQ> <xmx:cVGuXJcCmgspfS9ilvmBT5xI4bMthimuFIZlFuMmaTuT63nGzmpq1g> <xmx:clGuXAQgWUKSjA953eEmnlbBTEBdkLFubL0nDTLwZloiQEwd8OgmMQ>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B03DE452B; Wed, 10 Apr 2019 16:26:25 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBD675A@DGGEMM528-MBX.china.huawei.com>
Date: Wed, 10 Apr 2019 16:26:20 -0400
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CA1EEFD-D086-4900-A01C-9C3524275068@cooperw.in>
References: <b56bca60-c107-39c2-8cb7-5aede95731e4@alum.mit.edu> <9C5FD3EFA72E1740A3D41BADDE0B461FCFBD675A@DGGEMM528-MBX.china.huawei.com>
To: "Yemin (Amy)" <amy.yemin@huawei.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/xKfiNok9a5c86AQXVD_b2K03cd4>
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: Wed, 10 Apr 2019 20:26:28 -0000

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