[Gen-art] Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 23 January 2019 18:53 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 2410C130EF5; Wed, 23 Jan 2019 10:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 ytYs2JNUeR_4; Wed, 23 Jan 2019 10:53:50 -0800 (PST)
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 9E2371312B1; Wed, 23 Jan 2019 10:28:43 -0800 (PST)
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 x0NISf93005655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jan 2019 13:28:42 -0500
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: <5b0433e3-067c-0aa3-321b-7ebe5e67704d@alum.mit.edu>
Date: Wed, 23 Jan 2019 13:28:41 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.4.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/AmGiLlH0U-lZ9etD9a8Yx4bHuN8>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
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, 23 Jan 2019 18:53:53 -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 treat these comments just like any other 
last call comments. 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-13
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

Issues:

Major: 0
Minor: 1
Nits:  1

1) NIT:

Section 3.1 includes the following:

    ... The Ethernet SENDER_TSPEC object
    MAY include more than one Availability TLV. The Availability TLV has
    the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Index      |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Availability                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I find it confusing that this is described as a TLV yet it shows neither 
a type nor a length. Apparently it is only showing the value portion of 
the TLV. The type portion is only mentioned in the IANA considerations 
section, and isn't explicitly linked to this element. I would expect 
this to be shown something like:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type=4                     | Length=96                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Index      |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Availability                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(But the type value needs to be keyed to the IANA assigned value, since 
there is no guarantee that IANA will assign 4 for this.)

2) MINOR:

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]).

I have a question about this: Is this the default behavior that is 
prescribed for any unknown TLV type found in an Ethernet SENDER_TSPEC 
object, or is this behavior specific to the "availability" TLV? It is a 
problem if this is not the default behavior.

And is there a reason for SHOULD (rather than MUST) here? If so, please 
describe the situations where this need not be done.