Re: [CCAMP] Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

"Yemin (Amy)" <amy.yemin@huawei.com> Thu, 11 April 2019 10:10 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA9120299; Thu, 11 Apr 2019 03:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 i1a4mn5_8Ofm; Thu, 11 Apr 2019 03:10:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0B6181200F1; Thu, 11 Apr 2019 03:10:04 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 04E42DE9009084B74E89; Thu, 11 Apr 2019 11:10:02 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:10:01 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 11:10:01 +0100
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 11:10:01 +0100
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.72]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:09:34 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org>, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
Thread-Index: AQHU8D6rZ0M/p2Cdmkmw51aJBtjOtaY2unCJ
Date: Thu, 11 Apr 2019 10:09:33 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC055@DGGEMM528-MBX.china.huawei.com>
References: <155497048377.12789.13305027449937989152.idtracker@ietfa.amsl.com>
In-Reply-To: <155497048377.12789.13305027449937989152.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.156]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/bkRYbOUPaziHNPcUT9LoTeOcgbs>
Subject: Re: [CCAMP] Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 10:10:06 -0000

Hi Alexey,

Thanks for the comments. 
Benjamin also rasied the same comments, we will change the MAY to MUST. 

BR,
Amy
________________________________________
发件人: Alexey Melnikov via Datatracker [noreply@ietf.org]
发送时间: 2019年4月11日 16:14
收件人: The IESG
抄送: draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org; Daniele Ceccarelli; ccamp-chairs@ietf.org; daniele.ceccarelli@ericsson.com; ccamp@ietf.org
主题: Alexey Melnikov's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for a well written document.

I have a few easy to address comments.

Other people already commented on the lack of reference for the float format.

In the following text:

   When a node does not support the Availability TLV, the node SHOULD
   generate a PathErr message with the error code "Extended Class-Type
   Error" and the error value "Class-Type mismatch" (see [RFC2205]).
   When a node receives Availability TLVs which mixed of zero index and
   non-zero index, the message MAY be ignored and SHOULD NOT be

What does “MAY ignore” mean here and what are the implications of not ignoring?
I tend to think that this shoukd be MUST for interoperability, so either
changing this to MUST or adding explanatory text for MAY would address my
concern.

   propagated. When a node receives Availability TLVs (non-zero index)
   with no matching index value among the bandwidth-TLVs, the message
   MAY be ignored and SHOULD NOT be propagated. When a node receives

Same comment as above.

   several <bandwidth, availability> pairs, but there're are extra
   bandwidth-TLVs without matching index Availability-TLV, the extra
   bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated.