Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie
<ted.ietf@xxxxxxxxx> wrote:

>...
> Hi John,
> 
> My take on this is that this idea is worth exploring, and this
> document can take us down the right road for that by adding
> the caching clarification and removing the examples.  Removing
> the apparent force of the examples by clarifying that they
> indicate potential future lines of exploration rather than
> worked updates to the relevant standards also works for me.

Agreed.

> If we want to explore
> the idea in a .bogus.arpa subdomain rather than using
> sink.arpa, I don't think that's a big deal one way or the
other.

I guess the issue for me is that I want to see either 

	(i) Exactly one name allocated, with no hand waving
	about registries and other, similar names.  In other
	words, if someone later wants another
	allocated-but-not-delegated name, they go through
	exactly the same process as for this one, with the added
	obligation of having to justify "another one" to the
	community.
	
	(ii) A subtree delegation and setup, with a registry,
	but with the entries in that registry applying at the
	third level (e.g., sink.bogus.arpa.) and not as
	immediate subdomains of .ARPA.
 
> The real question for me is how do we get off the
> chicken-and-egg problem? If we have no document specifying the
> behavior of a guaranteed non-existent name, it is hard to get
> much actual deployment and experience, and I think that's what
> is required here.  We may well find that this works in some
> contexts and fails utterly in others, based on the silly
> domain name tricks pulled on a per-application basis.  But we
> can't find that out easily without an agreed upon way of
> trying this.
> 
> Maybe that makes this an experiment; maybe it makes it a
> likely-to-be-ephemeral best current practice.  But it does get
> the egg hatched, and that seems to be useful to me.

I'm ok with this, but it seems to me that the document now does
two things.  One is to set up the experiment (or possibly
long-term arrangement) that you describe above.  Another is to
set up a registry that would make little sense unless it had
multiple names in it and a mechanism for populating that
registry.  I'd like to either separate the two, move the
registry down a level in the DNS, or both.

    john


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]