On Mon, 17 Oct 2022, Suzanne Woolf wrote:
One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.
I've read the 6761bis draft (draft-hoffman-rfc6761bis), and it struck me as a
bit baffling that the proposed answer to a couple of cases of non-compliance
with a MUST in a standards-track registry policy document is to throw out the
MUST, rather than address a possible problem with approving or processing
requests.
I believe it is more than "a couple". I think Paul Hoffman has the
numbers.
More to the point, the questions are there to make sure that DNS operators (and others)
know what is required of their configurations and protocols in order to interoperate
between DNS and non-DNS operations and protocols that are using domain name conventions
for their names. The draft appears to propose keeping the original registry policy
("Standards Action or IESG Approval") while reducing the amount of information
required as a basis for a decision, which seems unlikely to make things any easier or
more effective for the IESG, DNS operators and implementers, or anyone else.
Seeing as we are in a 5+ year stalemate, I am not sure how it could not
be "more effective".
But I think you are mixing up two things. Entries under .arpa and new
"TLD like" entries. The latter has seen lots of pushback, including from
dnsops (eg the .home proposal getting pushed into home.arpa).
The entries for .arpa are well discussed, well formed drafts, and while
they might require special handling, most do not. Those who do are well
specified (eg resolver.arpa) and see full work done within their
respective WGs to reach RFC status in the proper way. And on top of
that, from now on will see review from the DNS Directorate as well.
TLD requests however, have always been a minefield and dnsop is not
the right place for discussing these. It often has fairly little to
do with the actual DNS protocol or operations.
Recall that the request for .onion (RFC 7686) was initiated under the same
registry policy we have today, and the IESG could have offered its approval
without DNSOP (or anyone else) providing a standards-track document taken
through normal WG process. They preferred giving it to the IETF WG whose
constituency is DNS operators and implementers.
The IESG handed DNSOP a problem to solve via https://www.ietf.org/blog/onion/
However, subsequent to this action, the IESG believes RFC 6761 needs
action, and substantial community input. It needs to be open for review
and modification because the current process is unscalable. Several
other names had also been submitted for consideration as special names,
and the RFC may not give adequate guidance about how when names should
be identified as special names. Special names should also be, as the
name implies – special and rare. The DNSOP working group is chartered
to address this RFC 6761 review.
But 7 years later, there is still no published 6761bis. I would therefor
argue that DNSOP has proven to not be the right place to do this. I do
not see how you can turn that into a "[the IESG] preferred giving it to
the IETF WG whose constituency is DNS operators and implementers.". I
mean the "preferred" in the past tense is correct. I am not sure the
current IESG still agrees after 7 years.
In other words, I've always thought that all of Section 5, including the MUST,
is there to support interoperability, and removing the requirement to provide
relevant information seems like a step backwards for that goal.
While that makes sense for entries in .arpa, it hardly makes sense for
new TLD-like domains that are per definition non-DNS (if they were DNS,
then ICANN should be dealing with those TLD names).
I think it draft would be better if it said something along the lines
of:
No code changes are required to properly handle leaked queries for .alt
into the DNS, but:
1) Implementations MAY handle .alt specially by (pre)fetching the proofs
of non-existence of .alt and serve these for all .alt queries.
2) implementations MAY rely on their query minimalization to accomplish 1)
3) or MAY do nothing special, which should work fine but might leak SLD
queries to the root if the implementation and its querier didn't do query
minimalization)
4) MAY return FORMERR on .alt queries that in some ways violate the DNS
specification (so that no code changes are mandatory to support the
madness .alt queries could bring in, eg >63 SLD names)
This is the kind of detail I think is important to provide in a document that's
essentially about interoperability, whether it's explicitly required or not.
Thank you.
Sure, it would be nice
