;[EMAIL PROTECTED]> wrote
> a message of 23 lines which said:
>
>> So what the heck is wrong with UK (as in the country code TLD of the
>> same name),
>
> It's true that there is a discrepancy between ISO 3166 and the root of
> the DNS. Do not worry, David Co
Frank,
On Feb 20, 2008, at 4:05 PM, Frank Ellermann wrote:
> Unfortunately IANA introduced EU as a new exception.
ICANN introduced the top-level domain for EU by request of appropriate
entities within the EU.
>> IANA has permitted the use of codes ISO designates as
>> "exceptionally reserved"
Frank,
On Feb 20, 2008, at 5:24 PM, Frank Ellermann wrote:
>> Neither of those documents needs to be updated since IANA
>> and ICANN are still using ISO-3166.
> When I ask whois.iana.org for CP, DG, EA, FX, IC, or TA it
> tells me that there's no such TLD.
Well, yes. They haven't been delegated
Frank,
On Feb 20, 2008, at 6:57 PM, Frank Ellermann wrote:
> They could make it worse if they add the "fantasy island codes".
They who? I doubt ISO-3166 MA will be adding "fantasy island codes",
but if they do, IANA is not in a position to deny the creation of TLDs
representing those codes.
John,
On Feb 20, 2008, at 9:31 PM, John C Klensin wrote:
> FWIW, this is a fairly radical re-interpretation of the policies
> IANA followed under RFC 1591 and even of any policy I'm aware of
> the ICANN Board having approved.
Given ICANN's board approved the EU delegation and AC and UK were
del
So is IANA and ICANN...
Regards,
-drc
On Mar 12, 2008, at 1:03 PM, Joao Damas wrote:
> http://plutarco.lab.bt.es/html/ipv6/global_results.html
>
> google now available over IPv6 at ipv6.google.com, just in time for
> the outage later today.
>
> Thanks to Juan Pedro Cerezo for running the website
> I'd prefer an IETF that serves the larger community over one that
> caters
> only to the few frequent contributors.
I'd prefer an IETF that can get things done in a timely manner.
Regards,
-drc
___
IETF mailing list
IETF@ietf.org
https://www.ietf.o
Lots of people have.
See http://www.iana.org/protocols/apply/
Regards,
-drc
On Mar 25, 2008, at 6:16 AM, Gupta, Kapil wrote:
Good Day All,
I have a question. Did any one try to register any port for his/
their application/service through IANA?
Please help.
Thank You,
Kapil
The informat
Hi,
On Mar 26, 2008, at 3:35 PM, Jim Fenton wrote:
> It seems there are two ways of looking at this:
>
> (1) records in the IPv6 world should do exactly same things as A
> records in the IPv4 world,
...
I don't really have a strong opinion on the whether or not s
should be used for ema
I'm sorry. What problem are we trying to solve again?
I thought we were talking about simply removing email addresses from
the blue sheets, but it seems we're talking about something entirely
different.
Thanks,
-drc
On Apr 4, 2008, at 2:11 PM, Bill Manning wrote:
>
> WIDE camps have done th
Hi,
On Jun 27, 2008, at 11:43 AM, Marshall Eubanks wrote:
I am curious as to whether others feel like this is a potential
problem to be addressed (and, not least, whether there is a better
mail list for this discussion).
I believe an RFC that provides an IETF-defined list of names (beyond
Hi,
On Jun 27, 2008, at 12:21 PM, SM wrote:
I believe an RFC that provides an IETF-defined list of names (beyond
the 4 in 2606) and/or rules defining names the "Internet technical
community" feels would be inappropriate as top-level domains would be
quite helpful.
Do you mean as in RFC 3675?
On Jun 27, 2008, at 3:22 PM, SM wrote:
It would cause problems if .local was given out. I don't recall
seeing any RFC requesting IANA to reserve it.
Right.
- a label consisting of all numbers
We already have 888.com. Some users may ask for .888 given its
significance in some cultures.
On Jun 28, 2008, at 9:35 PM, SM wrote:
The domain name may be confused with an IP address. That can be
avoided by not allocating numbers from zero to 255 as TLDs.
You need a bit more than that. Under MacOSX (10.5.3, and I suspect
most BSD derivatives at the very least):
% ping 127.1024
P
Stephane,
On Jun 29, 2008, at 11:41 PM, Stephane Bortzmeyer wrote:
a TLD is a domain like any other.
In theory, yes. In reality, no. Speaking technically, how would you
distinguish the top-level domain "127.0.0.1" from the IP address
127.0.0.1?
Regards,
-drc
__
are numeric string representations now, after 30 years
going to be outlawed? if so, on what basis?
?
I'm suggesting that there are technical reasons why strings comprised
of all numbers and those that start with 0x and contain hex digits
should not be TLD labels.
In theory, the
On Jun 29, 2008, at 8:31 PM, Frank Ellermann wrote:
| Executive summary: Obsoletes RFC 952, updates RFC 1123,
| defines toplabel = letter 0*61( ldh ) letdig
So, TLDs starting with a number but containing non-numerics would be
disallowed (I'm reminded of the fun long ago with 3com.com)?
Re
John,
On Jun 30, 2008, at 5:43 AM, John C Klensin wrote:
The other two things that seem to be getting lost in this discussion
is that one can write all of the RFCs one like, but rules like this
are ultimately useless unless ICANN agrees to them
ICANN has already deferred to the IETF on tech
On Jun 30, 2008, at 12:01 PM, Stephane Bortzmeyer wrote:
Speaking technically, how would you distinguish the top-level domain
"127.0.0.1" from the IP address 127.0.0.1?
A word while passing here: is there a document (RFC, Posix standard,
whatever) which says which is the right result in such a
On Jul 1, 2008, at 12:44 PM, Stephane Bortzmeyer wrote:
The host SHOULD check the string syntactically for a dotted-decimal
number before looking it up in the Domain Name System.
which seems to reply to David Conrad's question: if all the
implementations are correct, 127.0.0.1 will always be an
On Nov 8, 2008, at 4:07 PM, John Levine wrote:
And what does this have to do with the technical details of running
and using one? We all know that spam stinks and DNSBLs stink, too.
Unfortunately, the alternatives to DNSBLs are worse.
This whole discussion is confusing.
I thought the role
Tony,
On Nov 25, 2008, at 2:10 PM, Tony Hain wrote:
There is no valid reason for 66nat.
Then it will die in the marketplace and any standardization efforts
will simply fade away.
The only justifications being given are
'people will do it anyway', and 'we have to move quickly because
ven
Tony,
On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
Either way the
app developers will have to rely on topology awareness crutches to
deal with
the resulting nonsense.
Stuff they presumably already have to deal with because they'd like
their applications to be used in the real (IPv4+NAT)
On Nov 26, 2008, at 10:05 AM, John C Klensin wrote:
I also assume those clients will be performing validation
against a signed root zone,
Sure, if they configure their trust anchor according to
https://ns.iana.org/dnssec/status.html
(There are other testbeds too, but I don't recall where to d
Dave,
On Nov 27, 2008, at 10:03 AM, Dave CROCKER wrote:
If I understand the thread, so far, there is a current reality that
suffers from missing too many pieces of necessary DNSSec
infrastructure, documentation, maybe software, and definitely
training. Without all of these additional piece
Hi,
On May 24, 2006, at 4:06 PM, Jeffrey Hutzelman wrote:
On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear
<[EMAIL PROTECTED]> wrote:
Yes, the distinction between well known ports and just assigned
ports is
outdated. The overarching theme of the document is that the IANA
should
be
Hi,
On May 24, 2006, at 6:16 PM, John C Klensin wrote:
This is not correct. They do, indeed, assign values.
Yes.
They also apply some minimal rules in doing so.
IANA does a basic sanity check and if there is any question as to
whether a port should be allocated, we pass the request to a
maybe I've missed it, but is there a standard way of extending the
text format of zone files to recognize new RRs without recompiling
the server? and is there a standard way to distribute machine-
readable definitions of new RR types?
rfc3597
_
On Nov 22, 2006, at 5:42 PM, Hallam-Baker, Phillip wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Note it is possible to upgrade the DNS servers and *still*
have active directory support.
You lose the coupling of AD and DNS.
Why do you say this? There are at least tw
Karl,
On Nov 28, 2006, at 12:05 PM, Karl Auerbach wrote:
There is an ancillary issues that have not, to my knowledge, been
adequately researched, and that is the expansion in the size of the
response packets.
I suppose that depends on your definition of "adequately".
This will by itself m
Emin,
On Nov 28, 2006, at 5:31 AM, Emin Gun Sirer wrote:
we'd be happy if IANA just signed the single TLD delegations already.
IANA, of course, doesn't sign TLD delegations. Even the question of
who signs the root is a subject of debate since IANA doesn't actually
operate the distribution
Hi,
On Nov 29, 2006, at 12:52 PM, william(at)elan.net wrote:
I did not see any consensus on that issue when it was brought to
NANOG-m.
Interesting. I didn't notice any support for separating the 32-bit
quantity into two sections, but I remember many people decrying
the need for any separato
[apologies for duplicates]
Hi,
If people want a representation for 32 bit AS numbers different than
that described in draft-michaelson-4byte-as-representation-02, they
should come to a consensus very, very soon and tell IANA about it.
32-bit ASNs have been discussed for several years now
Sam,
On Feb 28, 2007, at 8:37 AM, Sam Hartman wrote:
I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work. Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a different s
Mark,
On Jul 2, 2007, at 6:49 PM, Mark Andrews wrote:
People arn't bashing NAT.
Oh, please. Sure they are.
They are saying that NAT is not
a appropriate for solution in a IPv6 world. It adds a lot
more complexity than just a stateful firewall.
A stateful fi
I'd offer that the OSI protocol stack was probably significantly more
reviewed than the TCP/IP stack.
At the very least, running code is an empirical proof that an
architecture _can_ work.
Rgds,
-drc
On Aug 1, 2007, at 8:35 AM, Eric Burger wrote:
My faulty recollection is that in our game
Hi,
On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote:
Which widespread IPv4 stacks?
I think it might be easier to identify stacks that don't disallow
240/4. I don't actually know of any widespread ones.
Rather than wall off the space as private and thus put it beyond
any use we
Marshall,
On Aug 9, 2007, at 4:38 AM, Marshall Eubanks wrote:
If someone came out with a specific idea backed by hardware,
though, is there a reason not to let
them go forward ?
I suspect it would be hard to say without knowing what the idea is...
Rgds,
-drc
__
Keith,
On Aug 18, 2007, at 2:04 AM, Keith Moore wrote:
yes, but it's unreasonable to expect a home user to not need to
subnet.
You're kidding, right?
You're actually expecting folks who couldn't set up VCR timers to
configure _subnets_?
Regards,
-drc
___
I'll take ease in renumbering over application transparency for any
large network.
I find this confusing as a concern - how often do you renumber?
How often do you want to change service providers?
Regards,
-drc
___
Ietf mailing list
Ietf@ietf.org
% dig @ns.iana.org . axfr | grep "IN DS" | awk '{ print $1 }' | sort
| uniq
:-)
Regards,
-drc
On Aug 23, 2007, at 10:32 PM, Mark Andrews wrote:
Mark,
On Fri, Aug 24, 2007 at 10:54:41AM +1000, Mark Andrews wrote:
This proposal is a way to move forward without waiting for
the polit
Dave,
On Aug 24, 2007, at 1:32 AM, Dave Cridland wrote:
I'm honestly struggling to see what the issue is here. I certainly
agree that renumering is a pain, but I don't follow why renumbering
is so significantly painful that it's worth breaking the network
for. I'm not saying it isn't, I jus
On Aug 24, 2007, at 8:46 AM, Iljitsch van Beijnum wrote:
On 24-aug-2007, at 17:28, David Conrad wrote:
If you obtain address space from a service provider and you decide
to change providers, you have (in most cases) two options:
renumber or deploy NAT.
Nonsense.
Sigh. I forgot to be
Iljitsch,
On Aug 24, 2007, at 10:03 AM, Iljitsch van Beijnum wrote:
Regardless of the theatrics, this statement is still incorrect. As
I said in my previous message, you can't keep the old addresses
internally either so all of this buys you nothing.
I suspect the number of people who NAT in
Keith,
On Aug 29, 2007, at 1:36 PM, Keith Moore wrote:
no demonstration has been made that what IETF provided is "not
operationally feasible".
Given the stunningly successful deployment of IPv6 ten years after it
has been standardized, I can see how you would say this.
IPv6 is fascinating
Mark,
On Aug 29, 2007, at 3:24 PM, Mark Andrews wrote:
The DLV operators only need this information up until the
root is signed. Once the root is signed the root's DLV will
go in and these will be removed.
If the root gets signed and you remove the DLV stuff, won't you
Mark,
On Aug 29, 2007, at 4:23 PM, Mark Andrews wrote:
If the root gets signed and you remove the DLV stuff, won't you break
any caching resolver that still has the DLV trust anchor configured?
No. Please re-read the quoted paragraph. The root's DLV
will be there.
Please re-
John,
On Aug 29, 2007, at 6:31 PM, John C Klensin wrote:
Are you prepared to answer the question as to when the plan for
getting the root signed as originally intended (whatever that
plan now is) is going to be executed?
I have no idea what was 'originally intended', so it is difficult for
m
because, in the end, ULA (whichever flavor it is) leads to IPv6-
to-IPv6
NAT.
Only if you think in IPv4 terms.
And telcos, cable companies, and my grandmother often think in IPv6
terms.
Itojun is most likely right. Most people (and large corporations)
tend to go with wha
I particularly agree with Mark's final sentence, there - if
renumbering is a problem, let's solve it.
How do you renumber the IP address stored in the struct sockaddr_in
in a long running critical application?
Regards,
-drc
___
Ietf mailing list
On Sep 13, 2007, at 11:43 AM, Tony Finch wrote:
On Thu, 13 Sep 2007, David Conrad wrote:
How do you renumber the IP address stored in the struct
sockaddr_in in a
long running critical application?
Applications that don't respect DNS TTLs are broken for many
reasons, not
just ne
Jari,
On Sep 13, 2007, at 1:05 PM, Jari Arkko wrote:
We had an opportunity to fix that, but we blew it.
I think everyone agrees that having that flexibility
(ease of renumbering, no routing explosion in the
core etc) would be good.
So would world peace, motherhood, and apple pie. What are y
Iljitsch,
On Sep 13, 2007, at 3:01 PM, Iljitsch van Beijnum wrote:
Disconnect current session, reconnect.
Uh, not unless your application has some sort of retry or
checkpoint-restart capability.
I think the way IPv6 handles this by deprecating the current
address but keeping it alive for som
Tony,
On Sep 13, 2007, at 5:29 PM, Tony Hain wrote:
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not, and you need to stop claiming that because it
confuses people
into limiting their thinking to the legacy IPv4 deployment model.
I&#
Dave,
On Sep 13, 2007, at 5:43 PM, Dave Crocker wrote:
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
That sort of equivalence statement applies when the new version is
a minor upgrade to the previous, rather than require massive
changes to the
On Sep 13, 2007, at 6:01 PM, Fred Baker wrote:
What would be Really Nice would be to in some way ensure that
applications never saw IP addresses at all - they *only* worked on
names, and maintained no knowledge in the application of what
address was used.
I always thought an opportunity wa
Bill,
On Sep 14, 2007, at 2:15 AM, Bill Manning wrote:
On Thu, Sep 13, 2007 at 05:29:39PM -0700, Tony Hain wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
beating this dead horse...
The official IETF state sport.
actually, David is profoundly wrong.
Frequently.
I
Mark,
I get renumbered in IPv4 today.
I suspect there is probably a question of scale here.
I wouldn't be surprised that a small home network with a limited
number of subnets and systems could be automatically renumbered.
I would be surprised if a network of any appreciable size c
Keith,
On Sep 20, 2007, at 6:19 AM, Keith Moore wrote:
The point is only that sooner
or later there will be pushback associated with routing pain, and when
that pushback happens people will look to solve their problems in
other
ways.
Yes. The solution chosen in the past has been to deploy
On Sep 24, 2007, at 9:31 AM, Olaf M. Kolkman wrote:
In response to my message:
The IAB, obviously, favors expedient deployment of DNSSEC in the
DNS root.
David Kessens asked:
Is there any activity by the IAB to achieve this goal ?
[1] http://www.iab.org/documents/correspondence/2006-05-15-IAB
John,
Which would those be?
Thanks,
-drc
On Oct 3, 2007, at 6:00 AM, John Day wrote:
If IANA had any resolve there are at least 25 -30 Class A blocks
that should be reclaimed and are not or should not be part of the
public Internet address space.
__
On Oct 9, 2007, at 9:43 AM, Tony Li wrote:
Any new design would have necessarily required more bits to address
more end systems. Making legacy systems interact with these
additional addressing bits without some form of gateway, NAT or
other translation would indeed be challenging. You're l
Michael,
On Oct 23, 2007, at 7:34 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
The following thread from ARIN's Public Policy Mailing List is an
example of what is wrong with the IETF's documentation of IPv6.
I look forward to seeing your draft.
Regards,
-drc
___
Ted,
We're serious about IPv6.
Unless something really unexpected occurs (e.g., the Internet breaks
when we insert s into the root hints), IPv6 addresses will be
available for root service via the normal mechanisms significantly
before the next IETF.
Regards,
-drc
On Dec 19, 2007, a
Just for clarification:
On Dec 22, 2007, at 1:33 AM, Franck Martin wrote:
David Conrad
indicated that IANA has received requests from four root server
operators, F, K, M, Y to add IPv6 addresses to the appropriate
files/databases to enable IPv6-only service for root name servers.
"Y&qu
Because the IAOC and ISOC are incorporated and do business in the US
and not Tanzania or Mongolia?
Regards,
-drc
On Jan 14, 2008, at 8:01 AM, Stephane Bortzmeyer wrote:
On Mon, Jan 14, 2008 at 07:51:58AM -0800,
TS Glassey <[EMAIL PROTECTED]> wrote
a message of 134 lines which said:
or is i
On Tuesday, December 3, 2002, at 01:19 PM, Marc Schneiders wrote:
On Tue, 3 Dec 2002, at 13:11 [=GMT-0800], Rick Wesson wrote:
dns naming debates don't belong on the IETF list.
Not even the technical scalabilty of the root-zone?
No. See the DNSOP working group.
there is a
sandbox created j
I remember when people thought OSI protocols took too long to
standardize... :-)
Rgds,
-drc
On Friday, February 21, 2003, at 12:25 AM, Erik Nordmark wrote:
Apparently, you aren't even aware that your changes will make all
non-bind
9 servers non-compliant. Had you been aware of that, it seems
Ted,
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote:
Michel,
I don't think something needs to be provider independent
to fit this bill. Getting a slice of the global address space from
some provider and choosing not route a porti
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a consequences of choosing someone new to carry
the traffic from t
Keith,
Operationally, the DNS shouldn't be hard. Common implementations
(unaugmented BIND, in particular) make it so. If you don't think so, look
at the results of the Men&Mice Domain Health survey
(http://www.menandmice.com/6000/6000_domain_health.html)
Implementation wise, the DNS _is_ hard,
On 6/7/02 7:27 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Sat, 08 Jun 2002 13:22:28 -, Franck Martin said:
>> I was wondering if the best system to build a global PKI wouldn't be the
>> DNS system already in place?
> No.
>
> 1) There's *NOT* a good mapping between the DNS and LDA
On 6/8/02 6:22 AM, "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote:
> DNS packets are limited to 512 bytes.
No they are not. They are limited to 64K. Even without EDNS0, a large
response can fall back to TCP. You know this.
> Few MTUs are larger than 1500.
What is the average size of a CERT (
On 6/8/02 3:01 PM, "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote:
> I was excluding EDNS0, since I thought it wasn't widely implemented.
It has been implemented in the latest version of BINDv8, it has always been
in BINDv9, and I believe it is in Microsoft's DNS server (not positive on
this). G
On 6/11/02 4:34 PM, "Eric A. Hall" <[EMAIL PROTECTED]> wrote:
>> The big deal is that some of the more restrictive ISPs may not permit
>> customers to bypass their DNS servers. Same as with HTTP interception
>> proxies.
> No, the big deal is that the roots and TLDs would be crippled from
> millio
On 6/11/02 6:15 PM, "Eric A. Hall" <[EMAIL PROTECTED]> wrote:
>> Why do you think the roots and TLDs would get millions of TCP queries for
>> their certs? Why would anyone want to get the certs of the roots or tlds?
> Why do you think anybody would cache them long-term if they were right
> there
On 6/11/02 6:51 PM, "Derek Atkins" <[EMAIL PROTECTED]> wrote:
> David Conrad <[EMAIL PROTECTED]> writes:
>
>> Why do you think the roots and TLDs would get millions of TCP queries for
>> their certs? Why would anyone want to get the certs of the
On 6/12/02 8:20 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
>> But I can do
>> this only if I can discover certs that *aren't* either in the set it hands
>> me or in my local set, and TLS says nothing about how to do this.
> Yes, because it's an edge case.
Scalability as an edge case. Hmm.
>
On Nov 23, 2012, at 5:46 PM, Sabahattin Gucukoglu wrote:
> It's Friday. Time to plug IPv6 some more. :-)
>
> http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/
>
> LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They
> avoided conflicts with RFC 1918 space b
Brian,
On Jan 12, 2013, at 1:36 AM, Brian E Carpenter
wrote:
> I object to making RFC 2050 historic without retaining at least the
> content of its Section 1 as an IETF BCP.
Which part of section 1 do you think has any relevance to the IETF as a BCP?
> While the IETF did formally hand over det
John,
On Jan 12, 2013, at 2:21 PM, John C Klensin wrote:
> However, I don't think the
> section of 2860 that you cite helps very much because there is
> another way to read it.
As you know, there are many in both high and low places who choose the
interpretation of 2860 that best fits their p
On Jan 12, 2013, at 7:14 PM, Randy Bush wrote:
>> RFC 2050 is outdated and historic and its status should be made to
>> reflect that truth.
> made your bed, sleep in it.
Mea culpa, but it's time to get out of bed.
> maybe learn not to do it again? nope.
To be clear, I think RFC 2050 was he
John,
Just to be clear:
On Jan 14, 2013, at 7:19 AM, John C Klensin wrote:
> On those general subjects -- that trying to open the question of
> 2050 is a rat hole and that we should not go down it, we
> completely agree.
If the choice is leaving 2050 as is or reopening it to update it to refl
[cc to routing-discuss...@ietf.org moved to bcc try to keep discussion splay
limited]
Hi,
Speaking for myself as one of the authors:
On Mar 17, 2013, at 5:35 AM, Abdussalam Baryun
wrote:
> I have four questions before following the request. Qs below; please answer,
>
> 1) Is this a historic
Dave,
On Apr 30, 2013, at 10:13 AM, Dave Crocker wrote:
> On 4/30/2013 10:11 AM, Doug Barton wrote:
>> As has been repeatedly pointed out in the discussion on both dnsext and
>> spfbis, it is NOT too late for SPF.
>
> As has repeatedly been pointed out, the market has already had plenty of time
Murray,
On Apr 30, 2013, at 11:29 AM, Murray S. Kucherawy wrote:
> I would also point out that it's not difficult, given a jumble of TXT RRs in
> a reply, to find any that start with a particular identifying substring which
> would mean "this is an SPF record", so let's nip that one in the bud
On Apr 30, 2013, at 11:12 AM, Dave Crocker wrote:
>> What is the IETF-approved timeframe in which "the market" is allowed to
>> accept/reject a particular technology?
> I've no idea what the lower limit is or should be, but I'm quite sure that 7
> years exceeds it by a very comfortable margin.
On Apr 30, 2013, at 1:20 PM, Dave Crocker wrote:
>>> I've no idea what the lower limit is or should be, but I'm quite sure that
>>> 7 years exceeds it by a very comfortable margin.
>> By that logic we should abandon IPv6, DNSSEC, EDNS0, etc.
> Gosh, David. I guess you win.
Gee Dave, great way t
SM,
On May 10, 2013, at 11:40 AM, SM wrote:
> In Section 2:
>
> "As such, allocations must be made in accordance with the operational
> needs of those running the networks that make use of these number
> resources and by taking into consideration pool limitations at the
> time of allocati
Hi,
On May 14, 2013, at 11:02 AM, David Farmer wrote:
> The third goal you refer to focuses on the need for "accurate registration
> information ... in order to meet a variety of operational requirements." I
> believe this to be a valid technical concerns of the IETF, it is difficult to
> ima
On May 23, 2013, at 7:44 PM, Melinda Shore wrote:
> So the question is why we aren't seeing more drafts, reviews, and
> discussions from people in Central and South America,
Language?
Regards,
-drc
Chris,
On Jun 18, 2013, at 8:57 AM, Christopher Morrow wrote:
> I'm not such a fan of the draft, mostly because it appears to remove
> some principles that some RIR folk hold up in their policy discussions
> as important... while not having a backstop in said policies to
> replace the originals f
On Mar 1, 2010, at 8:34 AM, Joe Baptista wrote:
> Please remember the Kaminsky dns bug did not identify a security problem with
> the DNS but the UDP transport.
The problem Dan Kaminsky exploited is a known weakness in the DNS protocol,
specifically that a 16-bit identifier space is too small.
Sam,
On Mar 24, 2010, at 7:58 AM, Samuel Weiler wrote:
> You typically don't see airline tickets drop very much in price.
Sure they do. For example, you can pay over $1000 for a business class seat
SFO->IAD on Virgin America if you book a week in advance or pay $250 over your
coach seat on t
On May 27, 2010, at 9:14 AM, Brian E Carpenter wrote:
> On 2010-05-28 02:44, Ole Jacobsen wrote:
>> I guess my point was more that this article actually quotes a *real*
>> expert rather than someone we've never heard of --- a more common
>> practice for the press. Whether or not you agree with D
On May 28, 2010, at 1:29 AM, Brian E Carpenter wrote:
> Today, most users are *not* behind ISP NAT or some other form of global
> address sharing.
An interesting assertion. I'd agree on the ISP NAT part. Not sure about the
"other form of global address sharing" part, since single NAT is addres
On May 28, 2010, at 8:57 AM, Arnt Gulbrandsen wrote:
> Consider bittorrent. Bittorrent clients generally can run behind NAT, but in
> that case they have to be on the same ethernet as the NATbox, so it's a safe
> bet that the bittorrent USER has a real address. Am I stepping out on a limb
> if I
On Jun 17, 2010, at 12:18 PM, Martin Rex wrote:
> Maybe because it would be a big waste of network bandwidth and close
> to a Denial of Service (DoS) attack if every client would try every
> IPv4 and IPv6 address in parallel that it can get hold of for a hostname.
In a world of broadband, gigabit
Martin,
On Jun 17, 2010, at 1:24 PM, Martin Rex wrote:
> I don't know what the broadbands for the average home users look
> like where you are, but here they're typically <= 640kBit/s upstream.
And? How much bandwidth does a parallel connection use up? Presumably if this
felt to be a problem,
On Jun 18, 2010, at 7:21 PM, Martin Rex wrote:
> EVERY server is trivially susceptible to DoS attacks.
> That is no such thing as a server that is not.
Not so interested in getting into a pedantic argument on DoS susceptibility.
> What you described is a client with a pretty selfish attitude
> th
1 - 100 of 171 matches
Mail list logo
