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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 28 March 2019 17:10 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 EF82C120283; Thu, 28 Mar 2019 10:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z9-Xw854Bt2m; Thu, 28 Mar 2019 10:10:45 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 512041202F3; Thu, 28 Mar 2019 10:10:24 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x2SHAMSx008266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Mar 2019 13:10:22 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Message-ID: <b56bca60-c107-39c2-8cb7-5aede95731e4@alum.mit.edu>
Date: Thu, 28 Mar 2019 13:10:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/eW3cbYTHCn4G-kwRb3Tqvy2SAV4>
Subject: [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, 28 Mar 2019 17:10:47 -0000

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.