These comments might be more usefully said in the relevant ICANN forums.
If you could suggest which ones those are, I can certainly send a note.
Like Paul, I just don't have time to follow all of the ever larger set of
ICANN processes.
Steve
On May 17, 2015, at 7:07 PM, Paul Vixie
On 5/18/15, 7:12 AM, John R Levine jo...@taugh.com wrote:
These comments might be more usefully said in the relevant ICANN forums.
If you could suggest which ones those are, I can certainly send a note.
Like Paul, I just don't have time to follow all of the ever larger set of
ICANN processes.
In message 1a3d420a-32cc-464f-ada5-401a9dc76...@nic.br, Rubens Kuhl writes:
Besides ccTLD, out of ICANN contractual reach, looks like TLDs from
Uniregistry (including ISC servers) and Neustar are the ones most
mentioned here. Any outreach attempt, successful or otherwise, with
Uniregistry,
Can we get DNS and EDNS Protocol Compliance added to the acceptance
criteria for nameservers for TLDs.
http://ednscomp.isc.org/compliance/tld-report.html
shows this is NOT happening. It isn't hard to test for. Eight dig
queries per server is all that was required to generate this report.
On May 18, 2015, at 4:50 PM, Mark Andrews ma...@isc.org wrote:
Can we get DNS and EDNS Protocol Compliance added to the acceptance
criteria for nameservers for TLDs.
http://ednscomp.isc.org/compliance/tld-report.html
shows this is NOT happening. It isn't hard to test for. Eight dig
Thanks for this, Mark. I’ll take a look at the report.
Regards,
--
Francisco.
On 5/18/15, 4:50 PM, Mark Andrews ma...@isc.org wrote:
Can we get DNS and EDNS Protocol Compliance added to the acceptance
criteria for nameservers for TLDs.
http://ednscomp.isc.org/compliance/tld-report.html
Besides ccTLD, out of ICANN contractual reach, looks like TLDs from Uniregistry
(including ISC servers) and Neustar are the ones most mentioned here. Any
outreach attempt, successful or otherwise, with Uniregistry, ISC and Neustar ?
Rubens
On May 18, 2015, at 8:50 PM, Mark Andrews
need therefore not to delegate it. But in the former case, one needs
a pretty good argument why we need anything stronger than ICANN's
policy statement that the names are blocked indefinitely -- certainly,
one needs a better argument than I don't trust ICANN, because it's
already got the policy
John Levine wrote:
...
I would be much happier with a statement that said the names are
blocked indefinitely, and here's the plan for the $4 million in
application fees we accepted for those names.
+1.
--
Paul Vixie
___
DNSOP mailing list
These comments might be more usefully said in the relevant ICANN forums.
Steve
On May 17, 2015, at 7:07 PM, Paul Vixie p...@redbarn.org wrote:
John Levine wrote:
...
I would be much happier with a statement that said the names are
blocked indefinitely, and here's the plan for the $4
On Wed, May 13, 2015 at 08:51:35PM -, John Levine wrote:
.corp, .home, and .mail, they've only said they're deferred and I
just don't believe that ICANN has the institutional maturity to say no
permanently.
The point that I keep trying to make is that, if that's what we think,
we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ted Lemon wrote:
George, I didn't get into your game theory because I think it's
irrelevant. The IETF process is not a fast process. If
parasitical organizations decide to try to get the calories they
need from us rather than from ICANN, I am
In article 0ee18e9e-e7d2-42e3-aee8-9a43c4032...@nominum.com you write:
On May 14, 2015, at 1:03 AM, David Conrad d...@virtualized.org wrote:
What qualitative difference do you see between those uses of numbers and the
use of TLDs like CORP?
Lack of scarcity.
+1
R's,
John
I got to air my view. I concur its not a majority view. I don't feel I have
to have the last word and I respect you really do think this is a good
idea, and even meets the technical merit consideration for the process as
designed.
So I'm pretty ok with people weighing this up on the strengths and
George, I didn't get into your game theory because I think it's irrelevant.
The IETF process is not a fast process. If parasitical organizations decide to
try to get the calories they need from us rather than from ICANN, I am pretty
sure they will quickly learn that this is futile. It might
We agree its a view well out of scope. I don't agree we should imagine this
_decision_ is devoid of consequence in the real world and can be treated as
a technical question with no other consideration. I think almost any
decision made on technical merit facing the questions of naming and
On May 14, 2015, at 11:21 AM, David Conrad wrote:
snip
However, as I said, how it is labeled is somewhat irrelevant. What matters to
me is figuring out the objective criteria by which we can determine whether
and/or how a particular label is being used so much that its delegation in
the
Ted,
But in the case of .onion, .corp and .home, we _do_ have such a reason.
Great! What is that reason so it can be encoded into an RFC, can be measured,
and there can be an objective evaluation as to whether a prospective name can
be placed into the Special Use Names registry?
Thanks,
On May 14, 2015, at 11:21 AM, David Conrad d...@virtualized.org wrote:
However, as I said, how it is labeled is somewhat irrelevant. What matters to
me is figuring out the objective criteria by which we can determine whether
and/or how a particular label is being used so much that its
Ted,
On May 14, 2015, at 1:03 AM, David Conrad d...@virtualized.org wrote:
What qualitative difference do you see between those uses of numbers and the
use of TLDs like CORP?
Lack of scarcity.
Sorry, I don't understand this response in the context of whether or not the
folks making use
Lyman,
I understand the desire to have objective criteria, but in this case your
call for a bright-line distinction between dangerous and not dangerous
labels is an obvious red herring.
It's not so obvious to me that dangerous/not is a red herring, particularly
since that was one of the
On May 14, 2015, at 4:10 PM, David Conrad wrote:
Lyman,
I understand the desire to have objective criteria, but in this case your
call for a bright-line distinction between dangerous and not dangerous
labels is an obvious red herring.
It's not so obvious to me that dangerous/not is a
I have a lot of agreement for what David is saying. What I say below may
not of course point there, and he might not agree with me because this
isn't a bilaterally equal thing, to agree with someone, but I do. I think I
do agree with what he just said.
I think that prior use by private decision
On May 14, 2015, at 1:03 AM, David Conrad d...@virtualized.org wrote:
What qualitative difference do you see between those uses of numbers and the
use of TLDs like CORP?
Lack of scarcity.
___
DNSOP mailing list
DNSOP@ietf.org
On May 14, 2015, at 3:42 AM, George Michaelson g...@algebras.org wrote:
I have a lot of agreement for what David is saying. What I say below may not
of course point there, and he might not agree with me because this isn't a
bilaterally equal thing, to agree with someone, but I do. I think I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/13/2015 05:51 PM, John Levine wrote:
which means that ICANN is sitting on $3.7 million in
application fees which they will presumably have to refund, as well as
five withdrawn applications from parties who got partial refunds and
would
Lyman,
It is neither: it is a DNS operational issue. A large number of people are
apparently squatting on CORP/HOME/MAIL. Delegation of those TLDs would thus
impact that large number of people.
I think it is inaccurate (and unhelpful) to refer to the people who have been
using
The distinction I'm making suggests why corp and onion seem different. They
are, in this
fundamental resolution nature.
I was under the impression that part of the problem with .corp was
that there were a lot of SSL certificates floating around. The
CAs are supposed to have stopped issuing
But I suspect you know this, so I'm unclear why you claim they're already spoken
for.
I wasn't clear -- the IETF should document that they're unavailable, just
like .ARPA and .TEST aren't available.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider
John,
On May 13, 2015, at 1:51 PM, John Levine jo...@taugh.com wrote:
The distinction I'm making suggests why corp and onion seem different. They
are, in this
fundamental resolution nature.
I was under the impression that part of the problem with .corp was
that there were a lot of SSL
On May 13, 2015, at 2:05 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
I think you're missing a distinction I was making, however, which is that we
should not be poaching on turf already handed to someone else. Managing
top-level domains that are intended to be looked up in the DNS --
On May 13, 2015, at 6:05 PM, David Conrad wrote:
John,
On May 13, 2015, at 1:51 PM, John Levine jo...@taugh.com wrote:
The distinction I'm making suggests why corp and onion seem different.
They are, in this
fundamental resolution nature.
I was under the impression that part of the
I think you're missing a distinction I was making, however, which is that we
should not be poaching on turf already handed to someone else. Managing
top-level domains that are intended to be looked up in the DNS -- even if
people expect them to be part of a local root or otherwise not actually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/13/2015 03:05 PM, Andrew Sullivan wrote:
we should not be poaching on turf already handed to someone else.
Managing top-level domains that are intended to be looked up in the
DNS -- even if people expect them to be part of a local root or
On Tue, May 12, 2015 at 11:28:36AM -0400, Ted Lemon wrote:
The use that ICANN has chosen to sell for TLDs isn't something the
IETF intended when we delegated that authority to them, so while I
think we should try to be good citizens, we don't need to feel
particularly guilty about taking
From: DNSOP [dnsop-boun...@ietf.org] on behalf of hellekin [helle...@gnu.org]
Sent: Tuesday, 12 May 2015 17:54
To: dnsop@ietf.org
Subject: Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some
reading material
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
How
On May 12, 2015, at 12:36 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
This is a bizarre argument. You don't get to kind-of delegate policy
authority this way. Authority was delegated, and if we don't like the
outcome we can go pound sand.
I think the IETF can develop a position on
On May 11, 2015, at 9:06 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
This makes me think that what we ought to offer ICANN is a mechanism
to make insertions into the special-names registry by different
criteria than the protocol-shift cases. The latter all fit neatly
into 6761's 7
On May 12, 2015, at 8:24 AM, Andrew Sullivan a...@anvilwalrusden.com wrote:
That'd be another answer; but given that the _result_ of the
registration in both cases would be the same, I'm inclined to say that
the registry we use ought to be the same one. I don't feel strongly
about it, but
I’ve been reading this whole discussion with great interest over the past while
and do intend on joining today’s call. In the midst of all of this I think two
points from Andrew and Ed have been helpful to my thinking:
On May 11, 2015, at 9:06 PM, Andrew Sullivan a...@anvilwalrusden.com
On Sat, May 09, 2015 at 11:08:00AM +,
Edward Lewis edward.le...@icann.org wrote
a message of 157 lines which said:
[0] As in name.onion. isn't a domain name, it's a string that
happens to have dots in it.
More than that since it also follows domain name semantics (for
instance, it is
On Tue, May 12, 2015 at 08:08:55AM -0400, Ted Lemon wrote:
I see your point here, but is that really the right thing to do? It seems
to me that the distinction you have drawn is a good distinction, but argues
for a separate registry for please don't send these to the root than for
these
On Tue, May 12, 2015 at 2:49 PM, Dan York y...@isoc.org wrote:
I’ve been reading this whole discussion with great interest over the past
while and do intend on joining today’s call. In the midst of all of this I
think two points from Andrew and Ed have been helpful to my thinking:
On May
On Tue, May 12, 2015 at 3:17 PM, Ted Lemon ted.le...@nominum.com wrote:
On May 12, 2015, at 9:12 AM, Warren Kumari war...@kumari.net wrote:
... and this is some of the point of the .ALT pseudo-TLD -- if you
want to use a TLD that does not get resolved in the DNS, make your
namespace look like
On May 12, 2015, at 9:12 AM, Warren Kumari war...@kumari.net wrote:
... and this is some of the point of the .ALT pseudo-TLD -- if you
want to use a TLD that does not get resolved in the DNS, make your
namespace look like YYY.ALT. This *will* leak into the DNS, but should
be dropped (NXD) at
On 05/12/2015 02:49 PM, Dan York wrote:
I’ve been reading this whole discussion with great interest over the past
while and do intend on joining today’s call. In the midst of all of this I
think two points from Andrew and Ed have been helpful to my thinking:
On May 11, 2015, at 9:06 PM,
On May 12, 2015, at 9:41 AM, Warren Kumari war...@kumari.net wrote:
Now, you still have the metric problem. How do you know that there
really are enough users of YYY.ALT to justify reserving YYY (or, YYZ
if YYY is already in use)? Dunno - but, you already have this issue. I
think a large
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
How does one join the meeting with XMPP?
I confirm that the WebEx software is not compatible with my OS.
==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQJ8BAEBCgBmBQJVUiIFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
On Fri, May 08, 2015 at 08:10:41PM -0700, Paul Hoffman wrote:
- Will the IETF require some specific metrics for RFC 6761 reservations?
- If yes, what are those metrics?
- If no, who makes the non-specific decision?
Increasingly it strikes me that RFC 6761 is trying to do too much.
On 5/7/15, 11:41, John Levine jo...@taugh.com wrote:
ICANN has a whole bunch of rules that mandate that once you've paid
the $185,000, you have to deploy a DNSSEC signed zone on multiple
servers, implement elaborate reservation and trademark claiming rules,
takedown processes, WHOIS servers, and
On 5/9/15, 1:10, Suzanne Woolf suzworldw...@gmail.com wrote:
I share David’s reservations about this— how do we objectively and
reproducibly distinguish “people are using these in private networks”
from “people are generating arbitrary traffic to the roots for these”?
One good characterization
Playing devil's advocate
(http://en.wikipedia.org/wiki/Devil%27s_advocate):
On 5/9/15, 3:54, John R Levine jo...@taugh.com wrote:
Let's say we found that there's some online thing we never heard of
before, but it turns out that 100,000,000 people in India and China use
it, it uses private names
On May 8, 2015, at 7:10 PM, Suzanne Woolf suzworldw...@gmail.com wrote:
I share David’s reservations about this— how do we objectively and
reproducibly distinguish “people are using these in private networks” from
“people are generating arbitrary traffic to the roots for these”?
I think
Besides Paul's valid what if it's 100,000?, how does an engineer
distinguish between 100x people and 100x organized bots?
I dunno. How do we know that the traffic for .corp and .home is from
people rather than botnets?
If there is a group of people using an identifier as you describe, then
I'd
On 5/9/15, 18:27, John Levine jo...@taugh.com wrote:
Besides Paul's valid what if it's 100,000?, how does an engineer
distinguish between 100x people and 100x organized bots?
I dunno. How do we know that the traffic for .corp and .home is from
people rather than botnets?
Through forensic
Mark,
home, corp and perhaps mail need special handling if we really
want to not cause problems for those using those tlds internally.
Why?
What objective criteria makes those TLDs special?
(note that I am not disagreeing, just asking for the methodology by which we
can declare some TLDs as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/08/2015 01:48 PM, David Conrad wrote:
Mark,
home, corp and perhaps mail need special handling if we really
want to not cause problems for those using those tlds internally.
Why?
*** Citing IETF92 slides by Lyman Chapin and Mark
What objective criteria makes those TLDs special?
Data reportedly shows extensive off-the-books use in private networks.
What data?
It's an obvious stability issue.
Agreed.
I'd probably put lan into the same group, no doubt to the dismay of
the South American airline group.
That's sort
Hellekin,
On May 8, 2015, at 10:50 AM, hellekin helle...@gnu.org wrote:
home, corp and perhaps mail need special handling if we really
want to not cause problems for those using those tlds internally.
Why?
these are the 3 names that were identified as posing operational
hazards by
I'm not, but name leaking is different to name use. I suspect mail
ends up being qualified whereas home and corp are actually used as
private tlds. This difference requires different handling.
From the viewpoint of the outside world, what would be different?
Regards,
John Levine,
In message 20150508194223.55320.qm...@ary.lan, John Levine writes:
The justification for removing home/corp/mail primarily appears to be becau
se they showed up
'a lot' at the root servers. Without characterizing this a bit better, it s
eems to me it would
be trivial to set up situations to
Depends on the name. Why do you call out home/corp/mail? Should LAN be
reserved or not? What's your criteria?
If you put it that way, it's a reasonable question. Will reply when I get
done digging.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please
In message alpine.osx.2.11.1505081704140.30...@ary.lan, John R Levine write
s:
For a mail a secure NXDOMAIN response saying that mail. doesn't exist
should be fine.
For foo.home you actually want a insecure response with a insecure
referal or at least you want DS home to come back as a
Is there any concern for the IETF in a policy that says “If you start
using an arbitrary name that isn’t currently in the root zone, you can
just get the IETF to protect it for you”?
It's a reasonable question, but I think a reasonable answer in some
circimstances is yes.
Let's say we found
And home routers are not the only place where validation occurs.
Ah. I said I was being obtuse.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
___
DNSOP
In the interests of maybe taking this argument a little further than we have
the previous n times….
On May 8, 2015, at 8:34 PM, John Levine jo...@taugh.com wrote:
home, corp and perhaps mail need special handling if we really
want to not cause problems for those using those tlds internally.
As long as we are taking this path, will the Special Use Names folks please
remove MX from the ISO 3166 list and
delete the TLD so as not to confuse email … MX is so overloaded.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 8May2015Friday, at 16:10,
registering something in a registry does not prevent someone from using it. it
suggests that there is already a use for the string.
it does not matter if that is an IANA registry or the registry that is the DNS.
There are -LOTS- of registries for strings. A classic case
was Bell Northern
John,
On May 8, 2015, at 12:42 PM, John Levine jo...@taugh.com wrote:
The justification for removing home/corp/mail primarily appears to be
because they showed up
'a lot' at the root servers. Without characterizing this a bit better, it
seems to me it would
be trivial to set up situations
For a mail a secure NXDOMAIN response saying that mail. doesn't exist
should be fine.
For foo.home you actually want a insecure response with a insecure
referal or at least you want DS home to come back as a secure
NODATA rather than a secure NXDOMAIN. This assumes we want to
formalise the
In message d170e3e4.1011f2%jason_living...@cable.comcast.com, Livingood, Jas
on writes:
On 5/6/15, 2:07 PM, Suzanne Woolf
suzworldw...@gmail.commailto:suzworldw...@gmail.com wrote:
2. In the particular cases of home/corp/mail, ICANN has
studied the possibilities of name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/06/2015 03:07 PM, Suzanne Woolf wrote:
Logistics details will follow shortly, but we have a webex URL
*** As far as I understand, WebEx requires non-free software to work,
which is a problem that will certainly make my participation more
Beyond that, does it end up being a cheap way to avoid the ICANN
process of creating a new gTLD. For example, I am not aware that
anything prevents the ToR project from applying to ICANN for the
.onion gTLD.
ICANN has a whole bunch of rules that mandate that once you've paid
the $185,000, you
On May 7, 2015, at 9:56 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
Beyond that, does it end up being a cheap way to avoid the ICANN process of
creating a new gTLD. For example, I am not aware that anything prevents the
ToR project from applying to ICANN for the .onion
Dear colleagues,
It’s taken a little longer than we initially expected, but we’ve been working
on agenda and discussion details for the interim WG meeting next week.
Logistics details will follow shortly, but we have a webex URL graciously
provided by the IETF secretariat.
We have the
75 matches
Mail list logo
