This is a language quibble. I said ICANN had no mechanisms for specifying how a
domain should be handled, and I would think a SHOULD specification is exactly
that in formal language. ICANN has no good mechanism to make recommendations
for DNS resolver behaviour of an undelegated domain, even min
I’d add that ICANN has no mechanism for specifying how a top level
domain should be handled other than the simple delegation/non-delegation
binary (it can specify how certain sub-domains should be handled as a
condition of delegation). It cannot, as the .onion proposal does,
specify that the do
I’d add that ICANN has no mechanism for specifying how a top level domain
should be handled other than the simple delegation/non-delegation binary (it
can specify how certain sub-domains should be handled as a condition of
delegation). It cannot, as the .onion proposal does, specify that the dom
>It seems to me that ICANN could well decide that certain names are
>just not going to be delegated in the DNS root, and could do that on
>the understanding that it is because of existing deployments. There
>is an argument to ne made that the "corp" and "mail" examples are of
>this sort, although
Dear colleagues,
On Mon, Aug 31, 2015 at 05:44:49PM -0400, Joe Abley wrote:
> Since the core problem here is that people are not realising that there
> really is no "forward" and "reverse" namespace (there's just a single
> namespace plus some conventions)
Loathe as I am to endure this again, th
> On Aug 31, 2015, at 5:11 PM, joel jaeggli wrote:
>
> On 8/31/15 1:04 PM, Alissa Cooper wrote:
>
>> I agree with Alvaro and Stephen's comments. In particular, to my eye
>> [tor-rendezvous] should be a normative reference given item #3 in Section
>> 2. However, it seems more important to publis
On Fri, Aug 21, 2015 at 08:15:26PM +0100, Stephen Farrell wrote:
>
> Do ICANN have any process for allocating special-use names that will
> not be used in the DNS? I am not aware of such but it may exist.
It seems to me that ICANN could well decide that certain names are
just not going to be dele
On 8/31/15 1:04 PM, Alissa Cooper wrote:
> I agree with Alvaro and Stephen's comments. In particular, to my eye
> [tor-rendezvous] should be a normative reference given item #3 in Section
> 2. However, it seems more important to publish this document than to
> re-issue the last call to call out a
In message , "Joe Abley" writ
es:
> Hi Petr,
>
> I have reviewed this draft.
>
> A couple of minor editorial nits aside, I think it does a good job at
> providing a solution to the problem it identifies.
>
> [You might consider using "initiator" rather than "requestor",
> incidentally; I thin
Hi Petr,
I have reviewed this draft.
A couple of minor editorial nits aside, I think it does a good job at
providing a solution to the problem it identifies.
[You might consider using "initiator" rather than "requestor",
incidentally; I think I first saw "initiator" and "responder" in one of
Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://w
This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.
The new IPv4 address for this authority is 198.9
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : DNS Terminology
Authors : Paul Hoffman
Andrew Sullivan
13 matches
Mail list logo
