This is not the Internet Debugging Task Force. People come to IETF meetings to get work done, not to debug operational issues.
Of course people should be doing research on operational impacts of the protocols being developed, bringing the results of that research to the relevant WGs, and adapting protocols to deal with them. The TLS 1.3 work has gone through this cycle several times.
However, just like the TLS 1.3 experimentation was not done on production servers that were meant for doing actual work, neither is the IETF network the right place to be discovering protocol issues. If people want to opt in, fine, but let's not make it the default.
On Sat, Jul 29, 2017 at 11:51 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
On 29/07/17 16:19, Ted Lemon wrote:
> The IETF is in the business of designing new networking protocols. If we
> are so allergic to dogfood that we can't even tolerate it for a week at a
> time three times a year, when there is an easy way to opt out, I think we
> ought to just stop spending millions of tons of carbon every year flying to
> these stupid meetings and go grow turnips or something.
- I quite like the occasional turnip, but hate the idea of
having to grow the feckers:-)
- I'm also fine with dogfood, e.g the DPRIVE test last time
worked just fine for me - even though I had to switch DNS stuff
about when switching from ietf-hotel to gsm, I was ok with that
as it was an opt-in and I'd opted-in.
- I don't like the sound of the query logging in section 3.1
of the draft, but am confident that the NOC folks wouldn't do
something bad there. It'd still be good to see that properly
described before any switch over, esp if as a default, as I
guess the draft is really aimed at a bigger audience who may
not be as clueful about privacy as our NOC team.
- I have no clue if Ubuntu supports this now - section 4.2
of the draft doesn't fill me with confidence, and I'm puzzled
as to how the draft figures ssh will continue to work "without
incident" given known_hosts has v4 addresses. And opting-in
here will change the state of known_hosts I guess in a way
that might in principle lead to attacks (that said I've not
checked what ssh clients know about dns64/nat64).
The above "corner cases", (not that I agree they are:-), the
DNSSEC stuff already mentioned together and Randy's figures
imply to me that this isn't yet ready to be a default, and
ought remain an opt-in.
I might try it out next time though.
One other note: if there were a perceived benefit for the folks
opting-in that'd help your cause I think. "You can help us all
make this better" is not a sufficiently direct benefit to attract
that many dogfood eaters IMO.
Cheers,
S.