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

"Ben Campbell" <ben@nostrum.com> Wed, 25 May 2016 21:24 UTC

Return-Path: <ben@nostrum.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 2DD4812DDB0; Wed, 25 May 2016 14:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 n_JmSbIsIKUZ; Wed, 25 May 2016 14:24:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1946712DDAE; Wed, 25 May 2016 14:24:15 -0700 (PDT)
Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4PLOA2L041725 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 16:24:10 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18]
From: Ben Campbell <ben@nostrum.com>
To: Rong Pan <ropan@cisco.com>
Date: Wed, 25 May 2016 16:24:09 -0500
Message-ID: <8DE122A0-157D-4245-AED1-CDAC87C5BB2C@nostrum.com>
In-Reply-To: <D36A18FE.188E4%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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/chdEr21Z1x-vWhTJI-0ca6CC59E>
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 21:24:16 -0000

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