When I wrote the problem statement I tried to do my best to document the implications of various actions that might be taken, including the 6761 registry. I think I did that in the "Domain Name Purity" section. Closing that registry is certainly something the IETF could do. However, there are significant implications if we do so, and we should understand those implications and either be prepared to do something to address them, or else accept that there will be consequences for not addressing them. We should not simply blithely close the registry thinking that that will be the end of the matter.
On Wed, Apr 6, 2016 at 5:32 PM, George Michaelson <g...@algebras.org> wrote: > As author of a brief, but pointedly direct draft which proposes > closing RFC6761, It should be understood that I do really, believe we > should close RFC6761. > > But I'm not blind to the pressures which make people want to "fix > things" and in that sense its sensible to discuss the problem, and > define a problem statement. > > I happen to believe that one solution includes closing RFC6761. I > don't think calling the solution RFC6761bis is going to help > distinguish the qualities which we need in deciding how to get labels > in the DNS, on technical grounds. > > Please don't misunderstand that to mean I think there is no role in > defining technical reasons for internet-names. I'd expect to see a lot > of discussion about why labels could be homed in .ALT but somehow > cannot be homed in .arpa (or, as Ted notes, in .test or other > delegated spaces during s/w development) > > I also believe the barrier to entry "or the 'height of the bar' as its > been put" should be kept high. A lot of the feedback I've received has > been how oppressive this is to s/w developers of good intent, and I > understand how frustrating it is to be blocked in time on IETF > process. I'm just aghast that the place people take themselves to here > is to functionally squat into the space they expect to be given, and > then claim a burden in software development to transit to where they > maybe should have gone (a configurable label, if any) > > -George > > On Wed, Apr 6, 2016 at 5:24 PM, Ted Lemon <mel...@fugue.com> wrote: > > it wasn't my intention to ignore the socio-legal issue, but the problem > > statement also can't presume a solution. I will think about this and try > to > > come up with better text. thanks for the feedback, both of you. > > > > On Wed, Apr 6, 2016 at 5:16 PM, George Michaelson <g...@algebras.org> > wrote: > >> > >> On Wed, Apr 6, 2016 at 5:07 PM, Alain Durand <alain.dur...@icann.org> > >> wrote: > >> > Reading section 4.2 and 4.3 of draft-tldr-sutld-ps-00, it would appear > >> > you > >> > are in the camp that does believe those “special names” are immune > those > >> > socio-economic pressures and/or the IETF can deal with this. Do I get > >> > this > >> > right? > >> > >> I too believe this is implicit in what ted wrote. > >> > >> > If that is the case, then, it is not that one document is better than > >> > the > >> > other, there is a fundamental difference between the perspectives of > >> > the > >> > authors. > >> > >> this too I agree with. > >> > >> It seems to me that there is a substantive issue which has to be > >> documented as "problem" > >> > >> Is the IETF actually the right SDO to define a label which has to be > >> added to a zone which the IETF gave substantive control over, to > >> another (non-SDO) body? > >> > >> I think that the socio-legal issues which vest inside ICANN cannot be > >> ignored simply because of a technical need/merit argument. Especially > >> when the technology claims a specific label, not just the concept of a > >> reservation for an otherwise unstated label. > >> > >> > > >> > It should follow that this is a non technical issue that is much > larger > >> > than > >> > DNSop wg. As such, the DNSop wg might want to refrain from adopting > one > >> > or > >> > the other document until the IETF, as a community, under the > leadership > >> > of > >> > the IAB, comes to an agreement on that fundamental question. After > all, > >> > the > >> > interpretation of RFC2860 (ICANN/IETF MoU) is the prerogative of the > >> > IAB. > >> > >> And it would come as little surprise that this too, I concur with. > >> > >> I like Ted's document. I liked it a lot. But without recognition of > >> this question of "who decides" I think as a document specifying the > >> problem statement, its incomplete. > >> > >> For me, it is simply not a "given" that the IETF is the right place to > >> determine labels in the top zone. > >> > >> cheers > >> > >> -George > >> > >> _______________________________________________ > >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
