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

Reply via email to