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

> -----Original Message-----
> From: Stephen Farrell [mailto:[email protected]]
> Sent: Wednesday, February 15, 2017 3:08 AM
> To: MORTON, ALFRED C (AL); The IESG
> Cc: [email protected]; [email protected];
> [email protected]
> 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:[email protected]] On Behalf Of Stephen
> Farrell
> >> Sent: Tuesday, February 14, 2017 8:45 PM
> >> To: The IESG
> >> Cc: [email protected]; [email protected]; MORTON,
> >> ALFRED C (AL); [email protected]
> >> 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
> >