On Sep 9, 2013, at 1:31 AM, Brian Trammell tramm...@tik.ee.ethz.ch wrote:
I must say at least that GPGMail (on the Mac) has gotten _much_ better in the
intervening decade.
+1
So far, it just works, and pretty much transparently. I've made my donation.
Regards,
-drc
signature.asc
On Sep 6, 2013, at 2:06 PM, Måns Nilsson mansa...@besserwisser.org wrote:
Right, because there's no way the NSA could ever pwn the DNS root key.
It is probably easier for NSA or similar agencies in other countries
to coerce X.509 root CA providers that operate on a competetive market
than
John,
Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.
The type number is 16 bits, after all. We're not in any danger of running
out.
We have been told on numerous occasions that one of the primary reasons for
continued use of
On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
The WG had a hard time coming up with really good data about what validators
look for, ... If someone else with some busy nameservers wants to provide
different evidence now, it wouldn't hurt.
Out of morbid
Scott,
On Aug 21, 2013, at 4:07 PM, Scott Kitterman sc...@kitterman.com wrote:
You could publish:
example.com IN TXT v=spf1 redirect=_spf.example.com
_spf.example. com IN TXT v=spf1 [actual content here]
Then delegate _spf.example.com to the mail administrator. Problem solved.
Wouldn't
Hi,
On Aug 19, 2013, at 12:10 PM, Scott Kitterman sc...@kitterman.com wrote:
Operationally, there are far more problems associated with actually trying to
use Type 99 than there are with SPF records in Type TXT.
Given the abysmal state of implementation of middleboxes _today_, this isn't
John,
On Aug 19, 2013, at 3:58 PM, John Levine jo...@taugh.com wrote:
AFAICT, no one is arguing that overloading TXT in the
way recommended by this draft is a good idea, rather the best arguments
appear to be that it is a pragmatic
least bad solution to the fact that (a) people often
On Aug 19, 2013, at 10:14 PM, Randy Bush ra...@psg.com wrote:
so, according to your message, one lesson i might take from this is, if
i want to deploy a new hack which needs an rrtype, not to use txt in the
interim. i will be caught in a mess which will appear to be of my own
making. is that
Chris,
On Jun 18, 2013, at 8:57 AM, Christopher Morrow morrowc.li...@gmail.com 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
On May 23, 2013, at 7:44 PM, Melinda Shore melinda.sh...@gmail.com 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
Hi,
On May 14, 2013, at 11:02 AM, David Farmer far...@umn.edu 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
SM,
On May 10, 2013, at 11:40 AM, SM s...@resistor.net 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
Dave,
On Apr 30, 2013, at 10:13 AM, Dave Crocker d...@dcrocker.net 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
Murray,
On Apr 30, 2013, at 11:29 AM, Murray S. Kucherawy superu...@gmail.com 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
On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net 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
On Apr 30, 2013, at 1:20 PM, Dave Crocker d...@dcrocker.net 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,
[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 abdussalambar...@gmail.com
wrote:
I have four questions before following the request. Qs below; please answer,
John,
Just to be clear:
On Jan 14, 2013, at 7:19 AM, John C Klensin john-i...@jck.com 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
Brian,
On Jan 12, 2013, at 1:36 AM, Brian E Carpenter brian.e.carpen...@gmail.com
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
John,
On Jan 12, 2013, at 2:21 PM, John C Klensin john-i...@jck.com 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
On Jan 12, 2013, at 7:14 PM, Randy Bush ra...@psg.com 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
On Nov 23, 2012, at 5:46 PM, Sabahattin Gucukoglu listse...@me.com 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
On Aug 10, 2012, at 10:22 AM, Andrew G. Malis agma...@gmail.com wrote:
Another alternative is self-describing variable-length addresses,
again do it once and we'll never have to worry about it again.
Heretic! That's OSI speak! Why do you hate the Internet you ISO/ITU lackey?!?
/flashback
Brian,
On Aug 8, 2012, at 12:52 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
If they are connected external to your network then obviously they would
have to be restarted ... but then you know that already. :)
And any mission-critical application that can't survive a disconnect
On Aug 2, 2012, at 12:55 PM, SM s...@resistor.net wrote:
If the ITU-T wants a /16 it is simply a matter of asking the IETF for it.
And, unless the reason the ITU-T was requesting the /16 was for some protocol
that came up with that has global applicability that needed a /16 of IPv6
space,
On Aug 2, 2012, at 11:44 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
we should instead focus on the ways that the technical architecture of
the Internet creates control points that are vulnerable to capture and
consider ways in which those control points can be made capture-proof.
On May 31, 2012, at 9:38 PM, Fred Baker wrote:
The IAB decides who acts as the IETF's IANA. RFC 2860 again.
http://ntia.doc.gov/page/iana-functions-purchase-order
You're correct that NTIA wants to pay someone to do the protocol parameter
job.
Err, pay isn't the right word here: it's a zero
On Apr 25, 2012, at 7:27 AM, Phillip Hallam-Baker wrote:
Except at the very lowest levels of the protocol stack (IP and BGP)
there is really no technical need for a namespace that is limited.
Arguable, but irrelevant since the reality is that historically many (most?)
protocols defined by the
Ned,
On Apr 25, 2012, at 10:46 AM, Ned Freed wrote:
I see no value in deallocating code point spaces and a huge amount of
potential harm.
It depends on the size of the space.
Why? We're talking about completed experiments. I'm unclear I see any
particular value in having IANA staff
Ned,
On Apr 25, 2012, at 7:31 PM, Ned Freed wrote:
I see no value in deallocating code point spaces
It depends on the size of the space.
Why?
Because if you deallocate and reallocate it, there can be conflicts. Perhaps
you haven't noticed, but a lot of times people continue to use stuff
Please don't feed the loons. All they do is poop all over everything.
Regards,
-drc
On Mar 26, 2012, at 7:09 AM, Christopher Morrow wrote:
On Mon, Mar 26, 2012 at 9:19 AM, Jim Fleming ietf.fact.ch...@gmail.com
wrote:
Was the U.S. FCC consulted about the 100/8 Address Spectrum usage ?
On Feb 16, 2012, at 8:58 AM, Nick Hilliard wrote:
The bottom line for this ID is that address space will be required for CGN,
and rfc1918 doesn't cut it for reasons described in the ID. This means
that the address space must come from somewhere else. The choices are:
1. one or more shared
I'm curious: how is the IETF stopping ARIN from allocating the space?
Thanks,
-drc
On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote:
(not voting twice, my other address did not seem to work)
+1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
+1.
Ross
From:
On Feb 13, 2012, at 12:34 PM, Doug Barton wrote:
If an ISP can't use a shared block, they'll go ask their RIR for a block -
and given that they demonstrably have the need (lots of customers), they
will get it. Multiply than by N providers.
If the RIRs do not deny these requests there is
Mans,
On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote:
To sum things up, we are at the stage where a /10 is a laughable
proposition.
Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs
can confirm.
It is either 10/8 or squat. No other alternatives exist. I'd
Ron,
On Feb 9, 2012, at 12:40 PM, Ronald Bonica wrote:
At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs
ask for a /10 for CGN, we burn one of those /8s.
Is that really a good idea?
Long ago, I once proposed a policy at ARIN to try to extend the IPv4 runway.
One
Michael,
On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote:
The CGN space seems like a very good place to use 240.0/10.
I believe the main driver behind this discussion is the need to deal with
deployed non-field-upgradable CPE that has issues with having RFC 1918 space
being assigned on
Frank,
On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
The last state I'm aware of is that the 240/4 addresses minus one
were and still are (RFC 5735) reserved for IETF experiments, did I miss
some newer IETF consensus about this?
...
Wes,
On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
Independent of whether we have any left, continued support for IPv4 in the
home and enterprise is *non-negotiable*,
True, however as I understand it, this isn't the issue. IIUC, the problem
isn't what happens in the home and enterprise,
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN deployment is a new deployment and the ISPs choosing to do this
could make sure that their customers CPE can support class E addresses,
upgrade the CPE firmware,
I think the ISPs are saying that there is a non-trivial base of
John,
On Dec 5, 2011, at 1:13 PM, John C Klensin wrote:
this is a much stronger argument for a dear customer, either renumber or
upgrade your
hardware position
I'd imagine the vast majority of the customers of ISPs who are facing this
issue would react either with anger or non-comprehension
Ron,
On Dec 3, 2011, at 2:06 PM, Ronald Bonica wrote:
- Is the reserved /10 required for the deployment of CGN?
Obviously not.
It isn't a question of whether CGN can be deployed, it is a question of how.
As far as I can tell, lack of the a new /10 will simply mean ISPs get to make
an
Hadriel,
On Dec 4, 2011, at 10:33 AM, Hadriel Kaplan wrote:
It isn't a question of whether CGN can be deployed, it is a question of how.
As far as I can tell, lack of the a new /10 will simply mean ISPs get to
make an operational decision, the result of which will either be more rapid
Doug,
On Dec 4, 2011, at 1:13 PM, Doug Barton wrote:
a) use normal space b) use somebody else's space c) redeploy stuff
d) Use 1918 space other than 192.168.[01]/24 for 90% of customers, deal
with one-offs for the rest.
I am making the assumption that the folks who have proposed draft-weil
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
We cannot use 1918 for CGN because some customers use it internally,
and they have CPEs that break if the same block is used on both sides.
Therefore, we need a new, !1918 block for our side of the CGN.
The problem with that argument is that
Chris,
On Nov 30, 2011, at 12:28 PM, Chris Grundemann wrote:
They will deploy CGN with or without us.
True.
We are giving them a way to do it in the least disruptive way.
Could you expand on the disruption you believe would be minimized by
implementation of this draft?
That is, what do you
[I haven't been following hybi and haven't read the draft, but as this is
posted to the ietf list and there are a bunch of assertions here about the DNS
I consider ... odd, I thought I'd chime in]
On Jul 24, 2011, at 8:59 AM, Willy Tarreau wrote:
A lost UDP packet is not retransmitted nor
[cross-posting greatly reduced]
Brian,
On Feb 28, 2011, at 10:35 AM, Brian E Carpenter wrote:
On 2011-02-26 10:34, bill manning wrote:
The IANA function was split?
RFC 2860 already did that.
I believe Bill was suggesting having multiple organizations perform the
different IANA functions.
Cullen,
On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision.
I think you are pretty
On Oct 20, 2010, at 1:36 PM, bill manning wrote:
My experiences with cache manipulation suggest there are many
other problems with the existing caching design as used by the DNS.
Such as?
Thanks,
-drc
___
Ietf mailing list
Ietf@ietf.org
Bill,
On Oct 20, 2010, at 1:58 PM, bill manning wrote:
right... but only rarely in the DNS world do edge nodes actually go hit
the authoritative sources. much/most of the time they hit a cache,
often
one run by a random third party.
I would truly love to see the data
On Oct 20, 2010, at 5:28 PM, Masataka Ohta wrote:
Richard Shockey wrote:
So what is your point ..you don't use phone numbers so the rest of the
planet shouldn't?
As PSTN will disappear, E.164 will also disappear, because there
will be no PSTN operator to maintain E.164 number space.
In the
On Oct 8, 2010, at 7:02 AM, james woodyatt wrote:
isn't it a bit unseemly to be arguing over how we went so wrong with IPv6--
and how we could do ever so much better the *next* time we get to reinvent
the Internet if we avoid all the killing mistakes we made in bringing IPv6
up-- while
Keith,
On Oct 7, 2010, at 4:32 AM, Keith Moore wrote:
As currently defined, IP assumes a global address space that is used
consistently throughout the network,
I actually think it's a bit worse than that. As currently defined, IP assumes
a global address space in which each individual
Noel,
On Oct 5, 2010, at 5:42 PM, Noel Chiappa wrote:
So whatever's going to happen when IPv4
addresses run out, a mass conversion of traffic to IPv6 probably isn't it.
Of course not. Obtaining IPv4 addresses will simply become more expensive,
with all that implies. Folks that depend on a
[I suspect you may know much of this, but just in case...]
On Sep 24, 2010, at 5:16 PM, John Levine wrote:
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
In general, consumers won't be using DNSSEC between their PCs and ISPs. PCs
On Aug 9, 2010, at 6:51 AM, Martin Rex wrote:
Joel Jaeggli wrote:
as much as 10% of of the partficipants might be remote, generally less,
almost never more.
There is a difference in the effectiveness of remote vs. on-premise
participation.
I don't think anyone disputes this (or even
Hi,
On Aug 6, 2010, at 4:36 AM, Ed Juskevicius wrote:
IEEE802 uses formal voting (during its meetings) to determine issues and to
accept proposals (or motions) to add or delete text from documents that are
being developed.
...
The IETF WG process is very different from IEEE802, and that
On Jul 1, 2010, at 12:32 PM, Iljitsch van Beijnum wrote:
I'm concerned about the correlation between my MAC address and the hosts I
communicate with.
Change your MAC address.
Regards,
-drc
___
Ietf mailing list
Ietf@ietf.org
Phillip,
On Jun 25, 2010, at 10:06 AM, Phillip Hallam-Baker wrote:
Am I the only person that thinks that if shaving 50ms off HTTP latency is a
worthwhile goal it would be more appropriate to look at a DNS based signaling
mechanism that is going to support that goal (and also do the right
Martin,
On Jun 23, 2010, at 6:06 AM, Martin Rex wrote:
What you described results in a negative incentive for servers to
become accessible under IPv6 as an alternative to IPv4. That is a real
problem.
I guess I'm not seeing how it is a significant negative incentive to servers.
If IPv6
On Jun 24, 2010, at 4:48 PM, Mark Andrews wrote:
The third choice is to do a non-blocking connect to IPv6 then if that does
not succeed in 1 or 2 seconds (most successful connects are within this
peroid but connect failures are considerably longer) initiate a non blocking
IPv4 connection and
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
that
Ned,
On Jun 17, 2010, at 2:18 PM, Ned Freed wrote:
Well, first of all, there are plenty of places that do not enjoy the benefits
of all that fancy stuff. What may be a tiny bit of meaningless overhead may
be something else entirely for someone else.
Perhaps. However, since connecting to the
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 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
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
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.
On Feb 25, 2010, at 6:16 AM, Florian Weimer wrote:
It's very slow if you don't have a cache.
Note that most stubs actually have a cache these days,
They do? Maybe that explains the 98% of the crap hitting the roots these
days...
Regards,
-drc
___
[For some reason, I seem to receive Phillip's messages later than other people
who are responding to his messages. Odd.]
Hi,
Signing the .com zone is irrelevant until we have a process for
putting the key in.
Not really. If VeriSign were to sign .COM tomorrow and publish their key
On Feb 25, 2010, at 8:41 AM, Paul Wouters wrote:
On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.
Trust no one.
You have to trust someone. Really.
On Feb 24, 2010, at 12:23 PM, Tony Finch wrote:
On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
And I have been asking ICANN for months how I get a key for my
DNS zones into the system and have never got a reply.
You should be asking your registrar and/or registry. In the mean time you
On Feb 18, 2010, at 12:10 AM, Masataka Ohta wrote:
For you, your ISP is, representing the Internet, responsible for the proper
delivery.
Your point?
You are aware, of course, that some ISPs are actively engaging in DNS response
modification, right?
To your surprise, reasonable security by
At 19:48 14-02-10, Phillip Hallam-Baker wrote:
IANA and ICANN have a really, really bad record when it comes to setting up
root authorities.
Oh? Examples please.
Regards,
-drc
___
Ietf mailing list
Ietf@ietf.org
On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote:
PEM (Five years and counting before the project faded away without a
definitive declaration of failure)
DNSEC (Ten years and counting)
So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and
DNSSEC.
Seriously?
On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote:
It is now generally accepted that PEM was undeployable because the
single root model is not workable.
And this is the fault of IANA and/or ICANN how?
ICANN was well aware that the lack of opt-out would prevent deployment
of DNSSEC in
On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
Who gets to decide on what algorithms get first class status and based on
what criteria?
If we look at what the CP developed in the SIDR WG for the RPKI says, the
answer is the IESG
So, they're going to flip a coin or what?
Who is largely
Dean,
Oddly, I've had none of the experiences you've had and I've been known to
travel a bit (1.6 million miles on United, top frequent flier honors on 3
carriers (UAL, NWA, JAL) simultaneously, etc.), including to quite a few places
where folks from the US weren't particularly popular. The
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
On Nov 6, 2009, at 9:30 AM, Phillip Hallam-Baker wrote:
Clearly the root operators are responsible to and accountable to the Internet
community.
Err, no.
First, the root server operators are all independent actors performing a
service for the Internet community for their own reasons. They
Eric,
On Sep 13, 2009, at 11:09 PM, Eric Rescorla wrote:
As Richard and I have both indicated,
however, this system seems to have substantial residual privacy
risk, even if the identifiers are assigned completely unpredictably
(and note that non-sequential and unpredictable are not at all the
Hi,
On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote:
But, in a DNSSEC environment, IANA performs two roles:
- it coordinates the info from the gTLDs and ccTLDs and
constructs
the authoritative root zone file
- it signs the records of that file
Nope. Just to
Alessandro,
On May 29, 2009, at 12:09 AM, Alessandro Vesely wrote:
One has to trust each cache!
With DNSSEC, you don't have to trust the cache since the only thing
the miscreants who compromise the cache can do is the functional
equivalent of removing the entry from the cache.
Given
On May 28, 2009, at 5:47 AM, Alessandro Vesely wrote:
I don't trust the data because it is signed, I trust it because the
signature proves that it originated from the authoritative server.
Not quite. The signature over the data proves that the holder of the
private key has signed the data.
Doug,
On May 28, 2009, at 2:36 PM, Douglas Otis wrote:
While DNSSEC may protect against data corruption, such protection
depends upon the thorny problem of verifying a key will be solved in
a practical and politically acceptable manner.
If you're talking about the 'who signs the root key'
Hi,
On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote:
I agree with Ned. The main purpose of the registry should be to
document what is out there, not to act as a gatekeeper. Even when a
protocol is not a full standard, having a public documentation is
useful. Documentation enables
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
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
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
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 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
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
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,
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)?
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
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 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
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
1 - 100 of 152 matches
Mail list logo
