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
