On 8/21/15 2:40 PM, Barry Leiba wrote: >> I'm pretty sure I'll be a yes ballot on this (after I re-read the >> draft which I've not read for quite a while). And I don't expect >> either of us to change our ballot, but that said, I hope you don't >> mind explaining your ballot a little more since I'm not getting part >> of your argument and that part could be relevant if/when other special >> use name drafts are processed. (Or if/when someone tries to win the >> race and first improve IETF handling of special-use names.) > > And I see you are a "yes", and I certainly have no interest in trying > to convince you or anyone to change or ballot a certain way. I'm only > expressing my own opinion here. > > My point here is that there were always other ways of doing this > besides using a made-up TLD, and it was always possible to use 6761 to > reserve a name early on.
That's an argument that this is moral hazard territory, I think that's a valid point, however with respect to 6761 the onion namespace substantially predates the existence of 6761 or the consensus documented there so I don't think the what if scenario is particularly helpful in looking at the problem of this draft. The thinking of the IETF community has evolved over time with the creation of the registry and the assignment of .local being a significant (and recent) milestone. > Neither of those paths were taken, which is > where my characterisation of "squatting" came in. It used to be > thought of as safe, if not entirely legitimate, to do that, because > only a relatively few things were valid TLDs. > > Now that ICANN has opened up the TLD space, it has become a clear > issue, and we're being asked -- and not because of work in the IETF -- > to retroactively protect this TLD from assignment to someone else by > reserving it for a particular software project. In general, I simply > don't think we should be doing that. In *this* case, I think doing it > serves the public good sufficiently that I'll accept that we've been > backed into it. In the general case, I think we should send > applicants to ICANN to make their case there. That fits under this > stipulation, from RFC 6761 Section 3: > > Reservation of a Special-Use Domain Name is not a mechanism > for circumventing normal domain name registration processes. > > I know there are a number of other TLDs waiting for this same > treatment, and, as I said, while I understand the need to proceed in > this case, I think it would be a mistake to continue doing this for > case after case of other such TLDs. If we to do more of this, we > should reserve one specific TLD for it (or use one we already have), > and have the uses migrate to that TLD. FWIW I think we have to address the problem of how to allow for experimentation in a way the does not result in future problems like this (that could have been avoided); or result in inadvertent pressure on the domain name system. But that's outside the scope (I hope) of this draft. > Barry > >> On 21/08/15 19:37, Barry Leiba wrote: >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I believe the IETF shouldn't be involved with registering special-use >>> TLDs for things that have been squatted on, and thus helping to >>> circumvent ICANN's normal process. >> >> The above confuses me. >> >> Do ICANN have any process for allocating special-use names that will >> not be used in the DNS? I am not aware of such but it may exist. I >> am also not at all clear that I'd accept that ICANN ought be in that >> particular business. >> >> Note: I am not saying what I think of, not asking what you think of, >> ICANNs new gTLD programme, but for the sake of this discussion, let's >> assume that programme is "normal";-) But that process is surely not >> one that could be used for special-use names that are required by >> protocols that require not using those names in DNS queries. >> >> Secondly, I don't get what you are saying you think about current IETF >> consensus (i.e. RFC 6761). Are you saying that: >> >> a) you don't agree with 6761? or >> b) that 6761 is fine but only for not-yet-deployed special-use names? >> >> If (a) I'm not sure that's our (IESG) role, and (b) seems highly >> unlikely to be workable (if one assumes an I-D has to wend its way >> through the process the special-use name will be deployed before IESG >> evaluation). So maybe you mean something else? >> >>> I know there are a bunch of other >>> such TLDs that people/organizations would have us snag for them, and I >>> very much want to avoid that nasty iceberg, of which this is the tip. >> >> That's why I'm asking my questions above - I do think there's more work >> to be done here amounting to some combination of improving 6761 and >> figuring out how to properly handle the other queued-up strings. >> >> In passing I have to say that I don't agree there's been nasty snaggy >> squatting on the tip of any iceberg, (sounds painful that:-) And in a >> pot-calls-kettle-black moment, I'm not sure that kind of language is >> guaranteed to help us resolve what is a tricky issue in a very tricky >> environment. But I guess crossing the streams of an anonymity overlay >> and DN$ was never going to end up very pretty;-) >> >>> That said, I well understand the deployed code involved and the >>> importance of keeping things working in this case, and I don't want to >>> stand in the way. So I'm standing aside with an "Abstain" ballot. >> >> Given what I think is your position, abstaining seems like the >> right action to take. >> >> I think you are quite correct that standing in the way here would >> have bad consequences. >> >> S. >> >> >>> >>> >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
