Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[George Michaelson <[e-mail]>]

None of these named spaces would "fail" to work as sub-spaces of .ALT
or .arpa or any other community-led IETF tech community managed label.

You haven't convinced me they innately need to exist as a TLD. The
sole entrypoint into that model, is a belief in what happens in the
browser bar and at the shell.

You are the designer of systems of world scale, I do not doubt. But
you are bringing an assumption to the table: all things of world scale
do not have to exist at the top of the worldwide name space.

I remain unconvinced. I remain of the belief, that shutting 6761 down
is wiser than racionation over the problem space, without recognizing
intractable elements to this problem because its not at root a
technology problem: its a name problem. We gave that role to somebody
else.

-G

On Thu, Sep 22, 2016 at 9:15 AM, hellekin <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote:
>>
>> And I'm still not convinced there is a problem to solve
>> (unless the real issue is "how to prevent the registration of .gnu and
>> .bit?")
>>
>
> Even if I supported the SUDN of P2P systems draft mentioning both .gnu
> and .bit, I see a great deal of difference between them. .gnu (and
> .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN
> response from DNS, and use their respective protocols to resolve from
> the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a
> special case in our I-D because it proposes an alternate way of DNS
> resolution, not using a delegated tree, but a blockchain.  With regard
> to DNS, .bit is different from the other five, besides the political
> effects of its specific approach (which I think should be able to exist
> anyway, for the sake of Internet End-to-End principle if nothing else.)
>
> None of the problem statement drafts took reference of the Special-Use
> Domain Names of P2P Systems which initiated this years long discussion
> that ended up with: should we revise or replace RFC6761.  In my position
> of editor of this draft, I don't really care what happens to RFC6761,
> but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and
> .bit.  I don't think any of the proposed problem statement drafts
> mention the perspective of actual P2P networks sharing their experience
> and their existence, and coming to the table with the idea of abiding to
> the IAB rule of a globally unique namespace.
>
> We say: hey, look, we exist, and we want to say that these are not
> transactional names: they bear cultural value.  They came from usage and
> the history of the Internet.  The DNS should know about them, so that
> people won't ever get into trouble trying to resolve non-existing names,
> or trying to resolve eventually delegated names that will collide with
> existing networks if they keep being ignored by DNS.
>
> I had the time to appreciate the nuances that IETF members can find in
> this seemingly simple approach, and try to generalize the issue: "what
> if others come and do the same? Who's responsible? How to judge of the
> legitimacy of those claims?" Etc.
>
> But what's been going on, from my point of view of volunteer who only
> has one life (that at least we share) and doesn't get paid for this
> work, is choking-by-bureaucracy.  People whose profession is to sit on
> IETF WGs can spend their time not solving issues, they still get food on
> the table.  And so production of norms is an endless process, and if not
> this one, another.
>
> As I see it, the problem we're trying to address is whether these P2P
> systems warrant some recognition from the Internet Community, is that
> something we want to encourage, or is that something that belongs to
> "the Deep Web", and we'd better leave that out of the picture?  I'm not
> talking about .mail, .corp, and .home, that belong to another category
> (I like "toxic waste"), or "people trying to circumvent IANA processes",
> or "don't want to pay", or "don't want to follow process".  We did
> follow process, once we realized there was one.  And suddenly, after a
> decade, everybody realizes there's an RFC6761 that really shouldn't have
> become an RFC in the first place, and this process is flawed, and we
> don't know how to handle this.  But when the Browser Forum comes with a
> deadline, consensus is easily achieved in no time, despite the draft is
> flawed with idiotic requirements such as "Users are expected to...".
>
> My take is that none of the proposed statement drafts took care of
> situating the debate in its (recent) historical context.  The fear of
> frictions between IANA and IETF have had more to do with how things
> went, than actual ponder of the technical arguments put forth by the
> various RFC6761-based drafts.  Case by case is not necessarily evil: not
> everything can nor should be automated.
>
> I believe that in the case of the 6 TLDs we asked for, there's little
> doubt they make sense technically, historically, and culturally.  That
> others may take it as 'a way in' and flood the IETF with stupid drafts
> 'just in case' seems to me the core of the problem, that was mentioned a
> few times over the years, but didn't make it through the recent drafts.
>
>> The rest of this email is about
>> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
>> and no.
>>
>
> This is a great summary, thank you!
>
> ==
> hk
>
> -----BEGIN PGP SIGNATURE-----
>
> iQJ8BAEBCgBmBQJX4xScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP
> v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS
> fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0
> 5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d
> KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ
> RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb
> S/Y6890dyJOa+014KUBdroGeH/MfZLHwKJELi6bs2wENkGp8ye6LwIOeJBOfJ47/
> 6Tt7ow+j9y05Xjh9lM1pOlQdlsusLmOHiBQ7cfWb1uo3XYCr5e86cUQ6S/3iBg17
> y0WfX1mFjWTvBnrLqMQrXTThiItMT+WN5JzkEcwfMv00oF62DQYh89WPzQ1SVSqQ
> vCQbCi5a25JfLtbS/LgJo4diXlnayMhJ5RtQIdBEbej2kO971eoYLxwma8jDB3gv
> mV8cJcjg4juj8Rpp0+eYsSNnOSlHcuZoaJBrpgd7XQNejuLZdR5/E3NmY1T+0Kif
> vVimJR3aa0C5SQQVFDxM
> =1b0u
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop