Re: [aqm] Ben Campbell's No Objection on draft-ietf-aqm-pie-07: (with COMMENT)

"Rong Pan (ropan)" <ropan@cisco.com> Wed, 25 May 2016 23:34 UTC

Return-Path: <ropan@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A2212D89C; Wed, 25 May 2016 16:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 ihxbmXuY_emJ; Wed, 25 May 2016 16:34:58 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9980812D842; Wed, 25 May 2016 16:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3736; q=dns/txt; s=iport; t=1464219297; x=1465428897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ERBTmOrm6A5UO+5/yVtTi2mwOhUgE6aQEJK/U7J/6X4=; b=JWZmZji9myoUzhVZr0Jgq5QpmiiK+GMVQoYkD7rPwQhkzHZJVaweOJTM XbCZxDEUH4axO67T3OOoATZgLd56zj5OccDhilkhOHseECGR704TUcQPj Zil5AwNDVG8Z8Zn868G+OxYmYjmnL+NZOKkLa9PTds3on74nsrQGCXkT5 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQDjNUZX/5tdJa1cgzmBUwa3Z4IdgXiGEQIcgSc5EwEBAQEBAQFlJ4REAQEENEUQAgEIGAQoAgIwJQIEDgWILgGUIZ0VBpFHAQEBAQEBAQECAQEBAQEBAQEfe4UshEyHOoJfBYgEkDMBjh+BaYRPiGSPSwEhAUCDbW6JFgF+AQEB
X-IronPort-AV: E=Sophos;i="5.26,366,1459814400"; d="scan'208";a="106131075"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 23:34:56 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4PNYubD005997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 23:34:56 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 18:34:55 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Wed, 25 May 2016 18:34:56 -0500
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-aqm-pie-07: (with COMMENT)
Thread-Index: AQHRsWtGl1dol5TfC0OorepJuBAqk5/HIzAAgAB40gCAAOwTAIACAHKA//+vMIA=
Date: Wed, 25 May 2016 23:34:56 +0000
Message-ID: <D36B8487.18986%ropan@cisco.com>
References: <20160519011042.14660.75883.idtracker@ietfa.amsl.com> <D368EE91.18841%ropan@cisco.com> <E5C0B715-6D2B-4771-A48A-17026896EE45@nostrum.com> <D36A18FE.188E4%ropan@cisco.com> <8DE122A0-157D-4245-AED1-CDAC87C5BB2C@nostrum.com>
In-Reply-To: <8DE122A0-157D-4245-AED1-CDAC87C5BB2C@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [171.71.130.224]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <A8DC633AF1E3FB439F6C94DF29211997@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/LXw_KmtqqG3LskrK7Ttr7HH0EDs>
Cc: Wesley Eddy <wes@mti-systems.com>, "aqm-chairs@ietf.org" <aqm-chairs@ietf.org>, "draft-ietf-aqm-pie@ietf.org" <draft-ietf-aqm-pie@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [aqm] Ben Campbell's No Objection on draft-ietf-aqm-pie-07: (with COMMENT)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2016 23:35:00 -0000

Sounds good, will change accordingly…

Rong

On 5/25/16, 2:24 PM, "Ben Campbell" <ben@nostrum.com> wrote:

>On 24 May 2016, at 16:50, Rong Pan (ropan) wrote:
>
>> I have specified whether a certain feature is optional or not. If an
>> implementor indeed decides to implement an option, then they
>> “should”
>> implement certain things specified in that section. I am afraid
>> “MAY”
>> would cause the optional feature not being implemented correctly.
>
>That's reasonable, but the draft doesn't seem to be worded that way. For
>example, 5.1 starts with, "PIE SHOULD support ECN by marking (rather
>than dropping) ECN capable
>packets". That SHOULD is ambiguous as to whether it applies to the fact
>of supporting ECN, or the mechanisms to be used if it is supported. I
>think most people will interpret that to mean both.
>
>Perhaps it should say something like "Implementations MAY support ECN
>marking. If they do so, they SHOULD..."
>
>There are similar "SHOULD" constructs in the other 5.x sections.
>
>>
>> Thanks,
>>
>> Rong
>>
>>
>> On 5/23/16, 5:45 PM, "Ben Campbell" <ben@nostrum.com> wrote:
>>
>>> On 23 May 2016, at 19:32, Rong Pan (ropan) wrote:
>>>
>>>> I am not sure how to address the following.
>>>>
>>>> Instead of ³SHOULD², what would be a good alternative word?
>>>
>>>
>>> The question is, are the features intended to be truly optional, or
>>> things people really should implement unless they have a really good
>>> reason not to?
>>>
>>> If the former, then you could change the SHOULDs to MAYs. If the
>>> latter,
>>> then you could describe them as "recommended" features vs "optional"
>>> features.
>>>
>>>
>>>>
>>>> Regarding ³experimental², Chair, Mirja, what would be the best way
>>>> to
>>>> address?
>>>
>>> I don't mean to speak for Mirja, but from my own perspective, there
>>> is
>>> language in the shepherd's write up that could be adapted for the
>>> introduction, or a short separate section.
>>>
>>> Thanks,
>>>
>>> Ben.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Rong
>>>>
>>>>>
>>>>> 
>>>>>----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> 
>>>>>----------------------------------------------------------------------
>>>>>
>>>>> In section 5 and its children: Please keep in mind that "SHOULD"
>>>>> does
>>>>> not
>>>>> mean quite the same thing as "optional".
>>>>>
>>>>> It would be nice to see some text about the nature of the
>>>>> "experiment".
>>>>> That is, why is this experimental? Do you expect to promote this to
>>>>> a
>>>>> standard in the future? (The shepherd's report speaks of this;  the
>>>>> draft
>>>>> should, too.)
>>>>>
>>>>>