ietf
[Top] [All Lists]

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

2009-12-23 02:33:40


--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie
<ted(_dot_)ietf(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>