On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
For 2.2.4, I believe all the names listed in 2.1.4 are also reserved
for second level domains and you are still missing a place
These are reasonable things to add, but I'm waiting to see if there's
agreement that it's worth moving forward.
On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
You're
At 05:39 05-01-2010, Jorge Amodio wrote:
On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
PSO might also have to be added then. According to information
published by IANA,
John Levine wrote on the IETF main list:
[ re _proto and _service names ]
...
Yes, I noticed that. As far as I can tell, the only _name entries
other than SRV protocols and services are _domainkey, _vouch, and
_adsp. It would be nice to collect them all in one place.
Yes, these underscore
I've done another version of my reserved names draft.
This time it proposes four registries:
1. Reserved and special top level names. ARPA is special, the others
are reserved.
2. Reserved and special second level names. EXAMPLE.COM, ORG, and
NET are reserved in the RFCs. ICANN has many
On Mon, 28 Dec 2009, John Levine wrote:
But I see little wisdom in adding another does-not-exist name with
semantics not meaningfully different from .INVALID or FOO.INVALID.
I think the semantics are meaningfully different, in that applications
are allowed to know that .invalid is special, but
In article 20091230172534.gb1...@apb-laptoy.apb.alt.za you write:
On Mon, 28 Dec 2009, John Levine wrote:
But I see little wisdom in adding another does-not-exist name with
semantics not meaningfully different from .INVALID or FOO.INVALID.
I think the semantics are meaningfully different, in
On 2009-12-30, at 14:13, John Levine wrote:
Aren't we arguing in circles here? The original proposal was for an
RFC to mark SINK.ARPA as special.
To be slightly pedantic, it was a proposal to make a policy decision that the
name SINK.ARPA should not be made to exist by those responsible for
Aren't we arguing in circles here? The original proposal was for an
RFC to mark SINK.ARPA as special.
The proposal did not seek to update the behaviour of protocols or applications
to treat SINK.ARPA any differently from any other name in the DNS.
Right. For all practical purposes, its
On 2009-12-27, at 20:16, John Levine wrote:
It seems to me that if we think it's a good idea to specify a domain
name that doesn't exist, we're better off clarifying the status of the
ones already specified rather than inventing new ones. Since the
people who manage .ARPA are the exact same
On Tue, Dec 29, 2009 at 01:02:54PM -0500, Joe Abley wrote:
If you're proposing that the IETF document a list of names that has
change control and authorship homed within ICANN, then I'm not sure
what the benefit of that is.
Setting aside the mind-bending metaphysical consequences of the
On Tue, Dec 29, 2009 at 12:16 PM, Andrew Sullivan a...@shinkuro.com wrote:
On Tue, Dec 29, 2009 at 01:02:54PM -0500, Joe Abley wrote:
If you're proposing that the IETF document a list of names that has
change control and authorship homed within ICANN, then I'm not sure
what the benefit of
It therefore seems to me to be not a bad idea to have an RFC or IANA
registry for the reserved names, in ICANN parlance. It would also
be good if some operational rules about what reserved names means
were in an RFC somewhere (for instance, are there different classes
of reserved names? Why?
On Tue, Dec 29, 2009 at 01:10:42PM -0600, Jorge Amodio wrote:
I believe that putting together a static list of something that is not
clearly defined when there is no clear policy for adding/removing
items from the list and no clear authority defined to execute the
policy and responsible to
Hi,
On Dec 29, 2009, at 11:56 AM, John Levine wrote:
There's also one special purpose
TLD, .ARPA, which is more or less delegated to the IAB although
managed by IANA.
RFC 3172 is pretty explicit about how ARPA is managed:
The Internet Architecture Board (IAB), in cooperation with the
I believe that putting together a static list of something that is not
clearly defined when there is no clear policy for adding/removing
items from the list and no clear authority defined to execute the
policy and responsible to keep the list updated will make the list
useless on day D-1.
On Tue, Dec 29, 2009 at 1:56 PM, John Levine jo...@iecc.com wrote:
It therefore seems to me to be not a bad idea to have an RFC or IANA
registry for the reserved names, in ICANN parlance. It would also
be good if some operational rules about what reserved names means
were in an RFC somewhere (for
Remove the leading dots, ICANN and IANA related names are reserved at
2nd and all levels.
In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA,
who knows?
R's,
John
___
Ietf mailing list
Ietf@ietf.org
On Tue, Dec 29, 2009 at 3:20 PM, John R. Levine jo...@iecc.com wrote:
Remove the leading dots, ICANN and IANA related names are reserved at
2nd and all levels.
In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, who
knows?
That's right, ccTLDs are a different dimension.
John Levine writes:
If other people agree that it's a good idea to have a place that IANA
can point to for the reserved names, I'd be happy to move this ahead.
Or if we think the situation is OK as it is, we can forget about it.
I'd be happier with some sort of list (I was surprised by its
I seem to have a problem with short words this week (can, to etc.).
They spontanteously mutate or disappear. Sorry.
Arnt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I think that in regards to the management and supervision of
.ARPA I'd suggest to include RFC3172 and RFC2860 as a reference.
I find that using the word Registry will IMHO create some
confusion with ICANNland.
The list of reserved names from ICANN's DAGv3 2.1.1.2 you
included in your message
Haai,
[not replying to anyone in particular]
I think we should make and maintain a seperation between two classes of
(reserved) symbols according to their fundamentally different origins:
-Required for one or more protocols to correctly function; and
-Reserved for administrative purposes (which
At 05:38 28/12/2009, Arnt Gulbrandsen wrote:
John Levine writes:
If other people agree that it's a good idea to have a place that
IANA can point to for the reserved names, I'd be happy to move this
ahead. Or if we think the situation is OK as it is, we can forget about it.
I'd be happier
On Dec 28, 2009, at 3:38 AM, Arnt Gulbrandsen wrote:
I'd be happier with some sort of list (I was surprised by its length, and IMO
that's a sign that the list is needed) and like your document.
+1
I can think of all sorts of other use cases for such a list, such as verifying
the accuracy of
On 28 Dec 2009 01:16:47 -
John Levine jo...@iecc.com wrote:
Here's their reserved list:
...
LOCALHOST
This one caught my eye, as I know for sure that localhost.tld seems
to be registered in most TLDs (both gTLDs and ccTLDs) by actual users
(mostly because I recently looked into purchasing
Here's their reserved list:
...
LOCALHOST
This one caught my eye, as I know for sure that localhost.tld seems
to be registered in most TLDs (both gTLDs and ccTLDs) by actual users
(mostly because I recently looked into purchasing one such domain).
ICANN reserves LOCALHOST as a TLD, not as a
[ re _proto and _service names ]
See:
http://www.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-00.txt
and older version of that is being split (second half is to contain the
registry cleanups).
http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04
Yes, I noticed that. As far
Since underscore labels are not considered normal DNS labels
for domains representing (roughly) physical hosts and networks,
everything below the topmost underscore label should not need
to go in a central repository for underscore labels but be
pointed to by the documentation referenced for the
It seems to me that if we think it's a good idea to specify a domain
name that doesn't exist, we're better off clarifying the status of the
ones already specified rather than inventing new ones. Since the
people who manage .ARPA are the exact same people who manage the root
(IANA, operated by
--On Monday, December 28, 2009 01:16 + John Levine
jo...@iecc.com wrote:
It seems to me that if we think it's a good idea to specify a
domain name that doesn't exist, we're better off clarifying
the status of the ones already specified rather than inventing
new ones. Since the people
31 matches
Mail list logo
