that's correct. It looks in that document like a quote from the IAB,
but if you're saying it's not, I then would have to challenge the
logical conclusion asserted in that second paragraph.
I don't see why it necessarily follows that having a single tree with a
single root creates a requirement for support for multiple resolution
protocols.
The thousands of authors of other protocols and systems don't seem to
have had too much trouble so far just using DNS where required, and
putting resolution into their own protocols outside the tree. Why break
the whole tree for some nebulous result which surely in all cases can be
worked around with a smaller consequence than having to deploy new DNS
to the entire world.
Even a DSL/NAT box does DNS forwarding, do we expect all those cheap
router box vendors to patch out the firmware for this any time soon?
Adrien
------ Original Message ------
From: "Robert Edmonds" <[email protected]>
To: "Adrien de Croy" <[email protected]>
Cc: "Paul Hoffman" <[email protected]>; "[email protected]"
<[email protected]>
Sent: 3/04/2016 8:11:37 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
You are complaining about the following text:
In [RFC2826] the IAB noted that
"To remain a global network, the Internet requires the existence
of a globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique
root."
Abley, et al. Expires September 9, 2016 [Page
7]
Internet-Draft Top-Level/Special-Use Domain Names March
2016
"Maintaining a globally-unique public namespace that supports
different name resolution protocols is hence an architectural
requirement, and some facility for reservation of top-level
domains in the DNS is necessary."
If [...]
From the context it would appear the second paragraph surrounded by
double-quotes is actually part of the main text of the document and not
a quote.
Note the indentation in the markup:
https://github.com/ableyjoe/draft-adpkja-dnsop-special-names-problem/blob/bd566c665630c96b415ed28caec48f27267d57c9/draft-adpkja-dnsop-special-names-problem.xml#L342-L354
Probably there is a missing <t> at the beginning of line 351.
Adrien de Croy wrote:
sorry, that second reference should have also been RFC 2826
neither the word "Maintaining" nor "architectural" are present in
2826
according to the search function in Chrome.
Adrien
------ Original Message ------
From: "Adrien de Croy" <[email protected]>
To: "Paul Hoffman" <[email protected]>; "[email protected]"
<[email protected]>
Sent: 1/04/2016 9:25:07 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
>
>
>------ Original Message ------
>From: "Paul Hoffman" <[email protected]>
>To: "[email protected]" <[email protected]>
>Cc: "[email protected]" <[email protected]>
>Sent: 1/04/2016 12:31:53 a.m.
>Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
>
>>On 30 Mar 2016, at 18:49, John Levine wrote:
>>
>>>Isn't it a little late to be refighting this argument?
>>
>>+1.
>
>I guess now we have some hindsight maybe we could learn from the
>experiences with .onion and maybe look differently at a proposal for
.alt.
>
>
>>
>>Folks: this thread is about a specific document, not every other
thing
>>we have discussed before now. If you want to rediscuss (as I
sometimes
>>do), please at least reference in the document where your argument
fits.
>>That way, the document authors can maybe amend the document if
there is
>>consensus to do so.
>Well I would start with what is presented as a quote from RFC 2826
which
>isn't actually in RFC 2686 and which seems to be the basis for a
claim of
>even doing a special use names registry at all.
>
>In Section 4. Architectural considerations
>
>"Maintaining a globally-unique public namespace that supports
different
>name resolution protocols is hence an architectural requirement..."
>
>Adrien
>
>
>>
>>--Paul Hoffman
>>
>>_______________________________________________
>>DNSOP mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/dnsop
>
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
--
Robert Edmonds
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
