On Sun, Oct 16, 2022 at 11:44 PM, Eliot Lear <l...@lear.ch> wrote:
> Hi Paul!
>
> Good conversation! I hope we can discuss some of this "in person"
> (whatever that means these days) at IETF 115.
>
> On 17.10.22 04:20, Paul Wouters 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.
>
> If what you are saying is that we shouldn't get hung up on 6761, then I
> agree. There are, I think, many ways to deal with the issue that Suzanne
> raised. One possibility not mentioned was to simply slap an
> "Updates" header on this draft if we think it's necessary, but that
> wouldn't be my first choice.
>
Note: I'm at NANOG this week (and also dealing with dayjob and some other
issues), and so I'm likely to be distracted and not able to focus on this
discussion as much as I'd like. Apologies in advance if I'm replying to
threads midway though / am terser than usual...
<no hats (this is for the entire ALT-TLD draft - Rob Wilton (CCed) is the
Responsible AD, but I will try to remember to insert the tag anyway)>
I really really don't think that "slap an "Updates" header on this draft"
is a good idea — the WG put a large amount of work into RFC 8244
("Special-Use Domain Names Problem Statement"). RFC 8244 lists 21 top level
issues and includes:
"This document has two goals: enumerate all of the problems that have been
identified to which Special-Use Domain Names are a solution and enumerate
all of the problems that have been raised in the process of trying to use
RFC 6761 as it was intended."
The document also notes that there have been cases where we've messed up
the process:
" 11. In some cases where the IETF has made assignments through the
process defined in RFC 6761, technical mistakes have been made
due to misunderstandings as to the actual process that RFC 6761
specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements, all of which must
be met). In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the process in RFC
6761 (see [RFC7050] and [RFC7788])."
Some of these process issue have included places where the IETF/IESG/IANA
missed that the fact that documents which added to the registry didn't
include the RFC6761 required bits ("The specification also MUST state, in
each of the seven "Domain Name Reservation Considerations" categories
below, what special treatment, if any, is to be applied.")
However, just because we screwed up in the past and added things to the
registry without following the process (and just because we think that some
of the questions are sub-optimal / inconvenient) doesn't mean that the
right thing to do is to just rip-em-out with an Updates tag. This is
especially true because of how much work the WG put into the "Problem
Statement" document - if there had been clear consensus that that was a
good idea we could have done it then.
I'll also note that while I personally think that some of the questions
could be worded better, the very act of filling them out focuses the
discussions and helps frame the answers in a manner which is useful.
Yes, my life as an author would have been easier not having to try and
figure out the answers to things like:
" 4: Are developers of caching domain name servers expected to make
their implementations recognize these names as special and treat
them differently?"
(See earlier discussion - differently to what? If the names are in the
Locally Served Zones registry does that count? Is it specifically
"developers" or "operators" (is this a "code vs configuration" question?)
But, the fact that I had to think about and answer them was really useful,
even if the questions themselves could have been better worded.
W
> The bigger issue is below. IMHO if we can kink that out, we have
> ourselves a ballgame.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD.
> [...]
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems.
>
> Let's please leave Internet lawyering to lawyers. If people want a legal
> opinion on this draft, the IETF does have resources for that.
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>
> I am struggling to parse that sentence, but taken together with this...
>
> Basically, .alt is what IETF recommends you should not do, and we should
> not keep
> a registry of entries within it.
>
> We cannot assume that DNS will forever be the only Good approach and that
> all others will forever be Bad. Given that, we as a community are obligated
> to search for better, and to try new things. As I wrote earlier, I do not
> know that GNS will succeed. I do hope and expect that the community will
> learn something from some deployment experience of that protocol so that
> the next one can be better.
>
> There exist many registries for things the IETF doesn't recommend. One
> need look no further than TLS 1.3 crypto-suites as an example.
>
> No matter what we say in the ALT draft, someone could burden the IETF with
> a new draft. People do so every day. If it gains sufficient support, it
> would have to be at least considered, no matter the topic. And again, I
> suspect most of these sorts of documents are more likely to flow to the ISE
> or perhaps a future IRTF RG. As the current ISE, that is a burden I would
> gladly bear, because there is the opportunity to help the Internet
> community, including the IETF and ICANN.
>
> I also have no problem rejecting trivial or bad proposals.
>
> Eliot
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
