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

Alissa Cooper <> Wed, 10 April 2019 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D07F120165; Wed, 10 Apr 2019 13:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key) header.b=oc0yOXv9; dkim=pass (2048-bit key) header.b=owSodzNf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8QLysOmhaN5; Wed, 10 Apr 2019 13:26:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D60101200C3; Wed, 10 Apr 2019 13:26:26 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 22A1021C08; Wed, 10 Apr 2019 16:26:26 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 16:26:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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 (unknown []) by (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 <>
In-Reply-To: <>
Date: Wed, 10 Apr 2019 16:26:20 -0400
Cc: "" <>, General Area Review Team <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Yemin (Amy)" <>, Paul Kyzivat <>
X-Mailer: Apple Mail (2.3445.9.1)
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: 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.


> 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