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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 24 January 2019 20:38 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 7C613130EF1; Thu, 24 Jan 2019 12:38:29 -0800 (PST)
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 cANy_Vy1YUSr; Thu, 24 Jan 2019 12:38:27 -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 7954612426A; Thu, 24 Jan 2019 12:38:27 -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 x0OKcJXP003171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jan 2019 15:38:19 -0500
To: "Yemin (Amy)" <amy.yemin@huawei.com>, "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>
Cc: General Area Review Team <gen-art@ietf.org>
References: <5b0433e3-067c-0aa3-321b-7ebe5e67704d@alum.mit.edu> <9C5FD3EFA72E1740A3D41BADDE0B461FCFB1AF8B@DGGEMM528-MBX.china.huawei.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <acfe7050-e24e-b032-09e0-a6ef82903610@alum.mit.edu>
Date: Thu, 24 Jan 2019 15:38:18 -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
In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FCFB1AF8B@DGGEMM528-MBX.china.huawei.com>
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/VUqlMI4fQLiruSy0bWj55zV0rE4>
Subject: Re: [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: Thu, 24 Jan 2019 20:38:29 -0000

Amy,

On 1/24/19 11:00 AM, Yemin (Amy) wrote:
> Hi Paul,
> 
> Thanks for the comments.
> Regarding nits: we followed the usual way, just show the value field. But I don't mind to make a complete figure.

In most places that define TLVs I see the type and length included in 
the figure. If the documents related to yours don't do that, and you 
want to follow that style, then please at least indicate in the text 
that you are only showing the value part, and explicitly call out the 
type and length.

> Minor issue: you're quiet right. It should be a MUST here.

You didn't mention my question:

>    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?

You can't mandate new behavior for things that don't implement this 
specification. If this is already the mandated behavior for an unknown 
TLV type then you technically don't need to say anything. If you want 
to, then best to reference the place that mandated this behavior. (I 
didn't find it in RFC2205.) And you could quote what that behavior is, 
or paraphrase it in a non-normative way.

	Thanks,
	Paul

> We will address these comments in next version. Thanks again.
> 
> BR,
> Amy
> ________________________________________
> 发件人: Paul Kyzivat [pkyzivat@alum.mit.edu]
> 发送时间: 2019年1月24日 2:28
> 收件人: draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org
> 抄送: General Area Review Team
> 主题: Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
> 
> 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.
>