Re: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-ipv6-nd-04: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 15 February 2017 08:07 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF511129554; Wed, 15 Feb 2017 00:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 2JrHw2K6lxrR; Wed, 15 Feb 2017 00:07:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE351294E5; Wed, 15 Feb 2017 00:07:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B16E8BE5B; Wed, 15 Feb 2017 08:07:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VccKNo8wWunj; Wed, 15 Feb 2017 08:07:39 +0000 (GMT)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8ACDFBE3E; Wed, 15 Feb 2017 08:07:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487146059; bh=YDsWHwVATy8vB0HnlRjxUTT2KoNVFb+SNROzFyR3isw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fJdW7ZfAMjRb4LdVx7IlL9bE/WByHL9jjy3qu/KNu5j3k4LZKw4mp7Pab7aQVsHGR BNMD/EXYgARfRp1/Ma8if13pEo4em9F1suXK5xu1msM6yjBBjCRRgFF5/B2K/iCnz4 go6F7IZm/Ifnx1UBuNwhU+a630V6ebXYlzgJ4cYw=
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, The IESG <iesg@ietf.org>
References: <148712312182.9946.220520091625731400.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF68B5FF@njmtexg5.research.att.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <374e00f4-b20e-b5ba-531b-9b53c411fca1@cs.tcd.ie>
Date: Wed, 15 Feb 2017 08:07:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF68B5FF@njmtexg5.research.att.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="b5MfM4RuJ7tbSh6BN5RkG3WnsXOoQS88d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/au9R6xPXaL6k3PlgO2O2ykJmyL4>
Cc: "draft-ietf-bmwg-ipv6-nd@ietf.org" <draft-ietf-bmwg-ipv6-nd@ietf.org>, "bmwg-chairs@ietf.org" <bmwg-chairs@ietf.org>, "bmwg@ietf.org" <bmwg@ietf.org>
Subject: Re: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-ipv6-nd-04: (with COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 08:07:46 -0000

Hi Al,

On 15/02/17 03:25, MORTON, ALFRED C (AL) wrote:
>> -----Original Message-----
>> From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Stephen Farrell
>> Sent: Tuesday, February 14, 2017 8:45 PM
>> To: The IESG
>> Cc: draft-ietf-bmwg-ipv6-nd@ietf.org; bmwg-chairs@ietf.org; MORTON,
>> ALFRED C (AL); bmwg@ietf.org
>> Subject: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-ipv6-
>> nd-04: (with COMMENT)
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-bmwg-ipv6-nd-04: No Objection
>>
> ...
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-nd/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> Just an idle thought... Given what we've learned about tests,
>> car manufs and diesel engines recently, I wonder if it'd be a
>> good idea for the security considerations sections of this
>> kind of RFC to consider how a DUT implementer might cheat?
>> In this case, I guess there could be a scenario where the
>> "clear the NC" operation is not really done (for a short
>> time, after a test pattern has been observed recently) so
>> that the DUT appears to perform better during tests. I'd
>> guess that some of the folks designing these tests thought
>> about some of that, but it might be no harm to start writing
>> that down as well. (Note this really is just a suggestion,
>> I'm not complaining at all. OTOH, while it'd be a bit of
>> work, it might be fun of a kind:-)
>>
>>
> [ACM] 
> Long before the emission test scandals, we had discussions on 
> manipulation of measurements in the context of the LMAP BoF. 
> Henning Schulzrinne wisely pointed-out that there are
> engineering problems, and then there are lawyer problems.
> 
> We subsequently wrote the LMAP charter to say:
> "Protection against the intentional or malicious insertion 
> of inaccuracies into the overall system or measurement 
> process (sometimes known as "gaming the system") is 
> outside the scope of work."
> 
> thankfully participating in the I*E*TF
> and leaving lawyer problems to the lawyers,

I fully agree that attempting to describe lawyer problems
wouldn't be a good plan. But, there are engineering issues
here that could maybe be usefully described too and it's
only the latter that I was interested in.

As you say, I do think that folks designing these benchmarks
do consider cheating DUT implementers at least a bit, so
the question is mostly if it's interesting to document
some of that thought. I'd find that interesting and suspect
it might be useful for those implementing or carrying out
tests.

Cheers,
S.


> Al
>