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

"MORTON, ALFRED C (AL)" <acmorton@att.com> Wed, 15 February 2017 13:40 UTC

Return-Path: <acmorton@att.com>
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 C21231295E8; Wed, 15 Feb 2017 05:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.487
X-Spam-Level:
X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 UqeRdHTLFZMz; Wed, 15 Feb 2017 05:40:08 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 A7F8F127071; Wed, 15 Feb 2017 05:40:08 -0800 (PST)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1FDZ6mh006914; Wed, 15 Feb 2017 08:40:02 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 28merqg854-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Feb 2017 08:40:02 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1FDe1SZ008445; Wed, 15 Feb 2017 08:40:02 -0500
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1FDdstv008340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Feb 2017 08:39:56 -0500
Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 15 Feb 2017 13:39:43 GMT
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v1FDdhia001971; Wed, 15 Feb 2017 07:39:43 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v1FDdXwT001390; Wed, 15 Feb 2017 07:39:34 -0600
Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id BB749E009C; Wed, 15 Feb 2017 08:39:32 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 08:39:32 -0500
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-ipv6-nd-04: (with COMMENT)
Thread-Index: AQHShy0w2qVVqcvzPku3zpXlvtU9E6FpZH5wgACmHICAAARjAA==
Date: Wed, 15 Feb 2017 13:39:32 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF68B80C@njmtexg5.research.att.com>
References: <148712312182.9946.220520091625731400.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF68B5FF@njmtexg5.research.att.com> <374e00f4-b20e-b5ba-531b-9b53c411fca1@cs.tcd.ie>
In-Reply-To: <374e00f4-b20e-b5ba-531b-9b53c411fca1@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.251.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-15_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702150132
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/5GMmgDrdccre5G3c01l_bslxvU0>
Cc: Scott Bradner <sobradner@gmail.com>, "draft-ietf-bmwg-ipv6-nd@ietf.org" <draft-ietf-bmwg-ipv6-nd@ietf.org>, "bmwg-chairs@ietf.org" <bmwg-chairs@ietf.org>, "Kevin Dubray (kdubray@juniper.net)" <kdubray@juniper.net>, "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 13:40:11 -0000

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, February 15, 2017 3:08 AM
> To: MORTON, ALFRED C (AL); The IESG
> Cc: draft-ietf-bmwg-ipv6-nd@ietf.org; bmwg-chairs@ietf.org;
> bmwg@ietf.org
> Subject: Re: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-
> ipv6-nd-04: (with COMMENT)
> 
> 
> 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.
> 
[ACM] 
Hi Stephen,
(disclaimer: this is a pre-coffee reply)

This is a topic where I would greatly appreciate to hear from
other long-time participants in BMWG, especially Scott Bradner
and Kevin Dubray.

To me, mentioning this topic in a standard passes more 
responsibility to the testing organization to check for it,
and incites the unscrupulous (catch me if you can). 

Also, there *are* checks we can perform to see if test 
conditions are recognized in the DUT, but we can't document
those methods in a standard because they will become
ineffective (magician's code of secrecy).

IMO, this is all better-handled by a code of conduct that 
the lawyers write and the DUT supplier signs.

regards,
Al 

> Cheers,
> S.
> 
> 
> > Al
> >