Hi,
> On Oct 16, 2022, at 10:20 PM, Paul Wouters <p...@nohats.ca> wrote:
>
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> > 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> > a problem for two reasons.
>
> 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.
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.
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.
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.
> 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.
Suzanne
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
