Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Paul Wouters <[e-mail]>]

On Tue, 2 Jul 2019, Petr Špaček wrote:

> Let me clarify that we (as DNS flag day organizers) are not even
> touching any RFC language because all the necessary pieces are already
> standardized (madatory TCP support + mechanism to handle EDNS buffer size).

If there is a security issue with fragmented DNS packets, perhaps that
warrants a new RFC document, possibly a BCP, that instructs implementers
what to do.

> Some people claim that IETF cannot put requirements on operators, only
> on implementations. We (as software and service vendors) are now saying
> "if you want to interoperate, you as an operator have to follow
> standards mandated for implementations", because in the end, what's
> mandated for implementation does not matter if operators ignore these
> requirements.

That is not different from the examples I gave earlier for those RFCs.
You can encourage/discourage or obsolete features. The good thing of
doing that in an RFC is that organizations and goverments and vendors
can point to it for compliance or policy and explain why it is done
a certain way.

> Of course it has to be explained to non-IETFers in many more words to
> eliminate requirement to read all the RFCs, but that's it.

If you think that, you haven't properly informed implementers via
existing RFCs. A new one is apparently needed. I don't see why this
should not be done here. This is dnsops. If you find an operational
issue, you write a clarifying or correcting RFC.

> Changing default EDNS buffer size is, I believe, in competency of
> individual implementations, so we as implementors will do a thing we
> deem sensible.

No one is saying you are not sensible. My point was that none of this
is a flag day, and the promotion to reach a few implementations via
"flag days" is better directed at writing a new or updated RFC that
explains the issue and recommends implementors what (not) to do. That
also helps downstream with customers wanting RFC ABC compliance, which
is a much stronger signal than compliance to "dnsflagday.net/2020".

> Let's continue discussion about dns flag day 2020 at mailing list
> [e-mail], please.

I'd rather not. Operational issues related to the DNS protocol
(mis)implementations or standard behaviour are well within the
charter of this group. DNS-OARC is a good venue to look at what
is happening, discuss why certain operational things are happening,
maybe brainstorm on how to fix it. Then coming to this group with
a proposal for a document to inform everyone and improve everything
is the right venue. It seems the problem and solution are already
well defined. It just needs to be written down in an RFC, and then
gradually software can implement the new behaviour. And again, if
for reasons vendors decide to implement it all on the same day to
ensure strict vendors are not unreasonably punished by being blamed
for failures, that's a reasonable goal. But seeing how upstream
vendors have no control over when downstream vendors pick up new
versions, the term "flag day" is just not the correct term to use,
and only brings up negative connotations in people being misled
into thinking IETF protocols needs flag days to continue running.

Paul