Re: [DNSOP] [EXTERNAL] Possible alt-tld last call?

[Paul Wouters <[e-mail]>]

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 to get something like this in for this document.

But it would be even nicer if we can be sure to close the "loophole" of
needing to discuss any further "TLD like" domains in DNSOP after this,
hence my desire for something like Paul Hoffman's 6761bis, where "TLD
like" things (after we do .alt) no longer need DNSOP, and in every case
I can think of now, should be rejected by the IESG or IETF review.

That is, we should never get more people back who squatted a string
(used or unused) that due to its large scale deployment, sort of forces
IETF to delegate a TLD for. Which to me seems to only objective
difference between the 5 TLDs that were originally requested in
draft-grothoff-iesg-special-use-p2p-names-00

Paul