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
> Uniregis
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 wrote:
>
Thanks for this, Mark. I’ll take a look at the report.
Regards,
--
Francisco.
On 5/18/15, 4:50 PM, "Mark Andrews" 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
>
>show
On May 18, 2015, at 4:50 PM, Mark Andrews 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
> queries per
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.
Mark
On 5/18/15, 7:12 AM, "John R Levine" 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.
I don’t
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 wrote:
These comments might be more usefully said in the relevant ICANN forums.
Steve
On May 17, 2015, at 7:07 PM, Paul Vixie 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 milli
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 li
>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 p
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 shou
-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
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 danger
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
On May 14, 2015, at 11:21 AM, David Conrad 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 delegation in
> the
> On May 14, 2015, at 11:21 AM, David Conrad 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 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,
-dr
Ted,
> On May 14, 2015, at 1:03 AM, David Conrad 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 of the space "o
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 an
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 bri
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
addressin
In article <0ee18e9e-e7d2-42e3-aee8-9a43c4032...@nominum.com> you write:
>On May 14, 2015, at 1:03 AM, David Conrad 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
__
On May 14, 2015, at 3:42 AM, George Michaelson 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 do agree
> w
On May 14, 2015, at 1:03 AM, David Conrad 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
https://www.ietf.org/mailman/listinfo/d
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 o
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
> usi
On May 13, 2015, at 6:05 PM, David Conrad wrote:
> John,
>
>> On May 13, 2015, at 1:51 PM, John Levine 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
On May 13, 2015, at 2:05 PM, Andrew Sullivan 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 -- even if
> people e
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 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 certifi
-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
> woul
>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
-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"
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 actuall
On May 12, 2015, at 12:36 PM, Andrew Sullivan 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 whether we think what IC
thing.
LOL!
/Hugo
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---
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 speci
-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
ZW5wZ3AuZmlmdGhob3JzZW1
On May 12, 2015, at 9:41 AM, Warren Kumari 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 amount of it
On Tue, May 12, 2015 at 3:17 PM, Ted Lemon wrote:
> On May 12, 2015, at 9:12 AM, Warren Kumari 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 i
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
On May 12, 2015, at 9:12 AM, Warren Kumari 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 the firs
On Tue, May 12, 2015 at 2: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,
On Sat, May 09, 2015 at 11:08:00AM +,
Edward Lewis 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 big-endian). So, yes,
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 wrote:
>
> It seems to me t
On May 12, 2015, at 8:24 AM, Andrew Sullivan 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 fewer registries 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
>
On May 11, 2015, at 9:06 PM, Andrew Sullivan 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 questions", but poli
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 muc
On 5/9/15, 18:27, "John Levine" 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 analysis.
>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
On May 8, 2015, at 7:10 PM, Suzanne Woolf 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 doing so would be a f
On 5/7/15, 11:41, "John Levine" 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 so forth.
Playing "devil's advocate"
(http://en.wikipedia.org/wiki/Devil%27s_advocate):
On 5/9/15, 3:54, "John R Levine" 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 in .SECR
On 5/9/15, 1:10, "Suzanne Woolf" 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 of the technical pr
> It's a reasonable question, but I think a reasonable answer in some
> circimstances is "yes".
>
> 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 in .SECRET, and people lo
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 foun
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 Res
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, Su
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 wrote:
>
>>> "home", "corp" and perhaps "mail" need special handling if we really
>>> want to not cause problems for those using those tlds internally.
>
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 mailing
In message , "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 secure
> > NODATA rather
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 consider
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 t
John,
> On May 8, 2015, at 12:42 PM, John Levine 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 to
In message , "John R Levine" write
s:
> > 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, w
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, jo..
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 s
>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 to move pretty much any undelegated name to
>the "Special Names"
>reg
>> 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'
>> "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?
Data reportedly shows extensive off-the-books use in private networks.
It's an obvious stability
Hellekin,
On May 8, 2015, at 10:50 AM, hellekin 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
-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
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
In message , "Livingood, Jas
on" writes:
> On 5/6/15, 2:07 PM, "Suzanne Woolf"
> mailto:suzworldw...@gmail.com>> wrote:
>
>>2. In the particular cases of home/corp/mail, ICANN has
>> studied the possibilities of name collisions, and decided not to delegate
>> those names at this ti
>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 h
On May 7, 2015, at 10:49 AM, Livingood, Jason
wrote:
>
> FWIW, it is not necessarily my opinion. I could just see people asking
> about it in that way - in which case the IETF needs to have a firm and
> logical response. I think some of the emails already sent have been
> helpful in this regard.
On 5/7/15, 10:41 AM, "Ted Lemon" wrote:
>I think this is an unfortunate way to look at the issue.
FWIW, it is not necessarily my opinion. I could just see people asking
about it in that way - in which case the IETF needs to have a firm and
logical response. I think some of the emails already sen
On May 7, 2015, at 9:56 AM, Livingood, Jason
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 gTLD. So from one
> perspective
-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 mor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/07/2015 10:56 AM, Livingood, Jason wrote:
>
> Beyond that, does it end up being a cheap way to avoid the ICANN
> process
>
*** It makes sense to follow that process for systems that use the DNS,
not for Special-Use Domain Names. If you would
On Thu, May 7, 2015 at 9:56 AM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:
> On 5/6/15, 2:07 PM, "Suzanne Woolf" wrote:
>
> c) The requests we're seeing for .onion and the other p2p names
> already in use are arguing that they should get their names to enable their
>
On 5/6/15, 2:07 PM, "Suzanne Woolf"
mailto:suzworldw...@gmail.com>> wrote:
c) The requests we're seeing for .onion and the other p2p names already
in use are arguing that they should get their names to enable their
technologies with minimal disruption to their installed base. While the
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 followi
84 matches
Mail list logo
