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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 14 Feb 2017 17:45:21 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-bmwg-ipv6-nd-04: 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-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:-)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Feb 2017 03:25:58 +0000

> -----Original Message-----
> From: bmwg [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, February 14, 2017 8:45 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; MORTON,
> ALFRED C (AL); [email-masked]
> Subject: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-ipv6-
> nd-04: (with COMMENT)
> 
...
> https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-nd/
[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,
Al

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2017 08:07:37 +0000

Hi Al,

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Feb 2017 13:39:32 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, February 15, 2017 3:08 AM
> To: MORTON, ALFRED C (AL); The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [bmwg] Stephen Farrell's No Objection on draft-ietf-bmwg-
> ipv6-nd-04: (with COMMENT)
> 
> 
> Hi Al,
> 
[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