[dns-operations] Operations vs. the lab (Was: What would it take...)

[Edward Lewis]

On 3/11/15, 15:32, "Doug Barton" <dougb at dougbarton.us> wrote:
>It's unfortunate that while on the one hand the IETF makes nice smoochy
>noises about wanting input from operators, on the other hand that input

On 3/12/15, 12:41, "Fred Morris" <m3047 at m3047.net> wrote:

>I'm not attending IETF events, so I don't know what is occurring, but this
>is one of the problems with gurus: not only do they irritatingly tell you


There's a divide between protocol engineers (the IETF) and operations,
that's for sure.  But basing it in the people in the two careers is
arguably not the best way to bridge the gap.

There are gurus and prima donnas and workhorses on both sides.  The IETF
is more visible than operators due to mailing lists.  And a lot of
operators work under direction to not interact publicly.

I've spent some time reflecting on why operators don't seem to be
represented in the IETF, partly thinking over the experience I had with
the ANY issue and now with issues related to the clumsy nature of DNSSEC.
I do recall laying out a plan to go to the IETF with an issue that was
nixed because we didn't feel that it would result in anything other than
bickering.  (Nixed by me too, not like upper management didn't like it.)
In some sense, we didn't even give the IETF a chance - whether the
reputation was deserved or not, we didn't see the IETF as accepting.

What happens then is that the IETF really has no input from operators, or
not enough.

So, this comes back to my original subject line - "what would it take..."
to break this stalemate?  How do operators come together to figure out
what set of tool improvements are needed?  (As you can see, I have one use
case, Tony described another, perhaps there are others.  I keep hearing
rumors about "what went wrong" with hbonow.com, no official, definitive,
derived from a through "root cause analysis" post-mortem account.

What is needed ... to make DNSSEC less clumsy?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150312/b1ae2a78/attachment.bin>