this a real
problem. I just don't think that the right answer is to break
perfectly well-functioning systems for everyone else in order to work
around clients that are implemented wrong.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing
On Tue, Mar 30, 2010 at 01:46:07PM -0400, Edward Lewis wrote:
Why is there a need to wean people off IPv4?
Because we're about to run out of v4 addresses, according to the
people in charge of giving them out.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
: The joyfully signs bit made me chortle.
Respectfully submitted,
Andrew
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Mar 17, 2010 at 03:51:42PM -0400, Paul Wouters wrote:
I think currently, a wrong DS trumps an updated DLV, but I have not
tested this recently on either bind or unbound. Is it specified anywhere
else what the expected behaviour is?
Good point. No, I have no idea.
A
--
Andrew
, where people
who remember some of the early decisions tend to hang out.
Best,
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
...@postel.org?subject=subscribe
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 2010-02-22, at 19:13, Mark Andrews ma...@isc.org wrote:
The problem is that one is using a hash, not the strength
of the hash.
Precisely. See another remark in this thread about excluded middle
and so on.
--
Andrew Sullivan
a...@shinkuro.com
for negative answer, Clear
text one uses NSEC record and the obfuscated one used NSEC3.
I didn't know how to rephrase that, because if I understand it I think
what I understand is wrong (but that's obviously not the case, so
probably I don't understand it).
A
--
Andrew Sullivan
a...@shinkuro.com
.
Since I think I've sung that refrain to everyone's boredom, however,
I'll shut up about it now.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote:
So many assumptions have changed...but the idea of KSK/ZSK hasn't.
Maybe this is the problem?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote:
At 10:39 -0500 1/21/10, Andrew Sullivan wrote:
Maybe this is the problem?
Problem?
It that it seems to be the occasion of a lot of disagreement with the
document. That is, in many cases, perhaps the advice should simply
On Thu, Jan 21, 2010 at 11:14:25AM -0500, Edward Lewis wrote:
At 11:02 -0500 1/21/10, Andrew Sullivan wrote:
Sure, but this may well be the exception and not the rule.
And I've heard the opposite. automated-registry[0]-run zones are in
the minority. (I.e., second level domains, third-level
keen we not put
anything resembling such language in any draft). That's all I was
saying.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of practice.
One also worries a little that many operations people (me included) so
often think you need to practice this includes in production.
(But I haven't worked many places where I've had a real, true,
complete copy of my production systems just for running fire drills.)
A
--
Andrew Sullivan
for the root, and that means I have to make trade-offs that might
be different than those for the root. Isn't that obvious?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Perhaps someone should take that up?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
view, either completely wrong or just
mostly wrong. (That includes using DNAME, by the way.)
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
think it would be tedious
to support this arrangement).
Best regards,
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
any discussion on that memo.
It certainly can use review. I am informed by someone who ought to
know that -01 is near to release, so if you haven't looked at -00 and
want to comment (and I urge you to do so), I counsel waiting until -01
is out.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro
done otherwise. But I
also claim that if we say, You shouldn't do $CHEAPTHING, you should
do $OTHERTHING, we're going to lose. We've lost every single time on
this. Why is now different? And if it's not, shouldn't we learn?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
that assumption, at least.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
me that in other contexts, a similar suggestion has been derided as
foolhardy, dangerous, and susceptible to evil behaviour by ISPs and
others.
Confused,
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https
the RRSIG in the cache
too, so that you don't accidentally get an RRSIG that does not in fact
cover the RRSet in your cache when using that cached RRSet (were you
to do that). Right?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP
coordinating with the behave chairs to get this resolved, which might
result in another re-scheduling. Please stay tuned ...
FWIW, I think this has been sorted out; DNS64 has been moved to the
first item in the Tuesday BEHAVE session.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, and I contend that such approaches are
always preferable.
Ay
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
regards,
Andrew
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
account. I'm
aware of how the accounting systems catch such access. I'm also aware
of how such access accounting breaks down.
Anyway, I completely agree that this is a cost-benefit analysis that
different sites have to do based on their use cases.
A
--
Andrew Sullivan
a...@shinkuro.com
the former, and one wants to argue for that, one will need a very
strong argument about which parts of the DNSSEC RFCs prove as much.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
'cuz I couldn't find it.
Not as far as I have been able to uncover. I'm just worried that
someone might have built something making that sort of assumption.
I'm glad to hear the answers are apparently, I don't think so.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
a use case that he wants supported.
Any feedback welcome. As I said at the mic, discussion is really
going on in behave; I'll happily take direct feedback as well.
Thanks for your time today.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
detail
yesterday.
Best regards,
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
in their implementation, they're
deployed. Interoperation is one of our more important values, and
that includes interoperation with reasonable interpretations of RFCs
that we nevertheless think are mistaken.
Best,
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
are in fact part
of it. Designing the protocols for the actually existing conditions
in the network is what makes the design activity engineering rather
than research, I think.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing
, we
want to do as little damage as possible. An argument in favour of
John Klensin's suggestion to make an explicit exception for IDNA2008
A-labels is that it is the smallest change that can be made that still
accommodates the new feature we want.
Best regards,
Andrew
--
Andrew Sullivan
know there are many DNS-using systems in the world
built around fragile readings of various RFCs. So I'm of two minds
about the position I've laid out above.
Best regards,
Andrew
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing
. IDNA). Or is there some other
thing you think ought to be permitted that would be closed off by
John's position?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is that one might try to
restrict numbers. My opinion, in any case, is that anything having to
do with U-labels is completely outside the scope of any document
focussed on the DNS: no U-label should ever be anywhere close to a
zone file.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc
that the current IANA-operated
root zone is in violation of RFC 1123, and try to prevent additional
movement on internationalized TLDs that way.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
, attempting to see if there is any argument for weakening
that position. So far, none, I'm delighted to say.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
in idnabis soon.
That's not my understanding of the issue so far.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, after all.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(perhaps redundant) defence against a line of attack, I support
it.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that does set the CD bit,
security-obvlious recursive resolver, security-aware server.
Have I missed something? Which of these are the cases where you think
(a) cache poisoning is possible at the recursive resolver and (b) the
stub resolver can be fooled by Mallory?
Best,
A
--
Andrew Sullivan
it correctly
handles all the DNSSEC-requesting questions from a stub resolver, and
correctly handles the data from a DNSSEC-offering server, in the case
where Mallory can win the race and answer the non-validating
DNSSEC-aware resolver before the legitimate server?
A
--
Andrew Sullivan
[EMAIL PROTECTED
policy
in the DNS itself!
Sorry for any confusion.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
have such an
attack, and it's not something that is already well-understood about
the protocol, I believe that everyone wants to see it as soon as
possible. I encourage you to perform your demonstration.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
for your indulgence,
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
what differences, if any, there are. When
.org is signed, that will be another opportunity to compare things as
well, I guess.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP
a slight change to the Kaminsky software.
Please outline exactly how you think this will work. I just re-read
section 5 of RFC 4035, and I can't see how it can, assuming you do in
fact have a set of valid trust anchors for some superordinate zone to
the victim domain.
A
--
Andrew Sullivan
[EMAIL
are not the only implementations,
and therefore that we will have surprise breakages during deployment.
I suspect this is a risk we will have to live with in the case of any
deployment of significant new DNS features, unfortunately.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
is going to say, So if
we never turned on DNSSEC, this wouldn't have happened? Ok. New
policy: no DNSSEC.
At least, that's the way it would have worked in most large
institutions I ever worked in/around.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
are involved and because it depends on proving trust
relationships; and because we know that humans make a lot of errors;
therefore, DNSSEC is only as strong as the operational practices of
the weakest point in the chain of trust?
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
today from what we're hearing in this thread.
So even if the hypothetical scenario is true, it's not a very strong
premise for the conclusion under discussion.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
this is a very bad idea, and I think it's a shame that it
should be adopted anywhere.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
. That seems
like a kind of harm to me, but I appreciate that we may have
different meanings of that word.
Best regards,
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https
or less guarantees the end of
the pretense of a unified namespace (which is related, I think,
to the arguments elsewhere in this thread that such has already
happened anyway).
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
On Thu, Apr 03, 2008 at 12:00:11AM -0500, Joe Abley wrote:
it's barely worth suggesting them. Call me cynical :-)
Or on the money. Whichever fits :-)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
. No, the temporary
address does not need to have a reverse mapping, for exactly the same
reason that it does not need a forward one.
I will attempt to come up with a sentence that makes this clearer,
given that it obviously isn't so far.
Best regards,
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503
.
I'm inclined to add this text. I'd like additional expressions of
support (or edits, or whatever) from the WG to confirm my inclination.
Thanks,
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP
into this
paragraph other issues of the utility of the reverse mapping. Does it
address your objection?
Again, thank you very much for your detailed comments and careful
review. Your editors appreciate it.
Best regards,
Andrew
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
,
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
alterations you could make to it such that I would think it a good
idea to adopt. I'm happy to look at additional revisions to the
document, however, if they address the above issues.
Best regards,
Andrew
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
are active in the IETF. This
is a subtle but, at least to me, important difference.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED
Dear colleagues,
On Tue, Jul 24, 2007 at 10:21:22PM -0400, Andrew Sullivan wrote:
Dear colleagues,
Stephane Bortzmeyer pointed out to me this morning a problem in what
section 2.1 of the -04 draft says. Here's how it reads now:
[. . .]
As there have been no additional comments
think they are used appropriately in the
-anderson- draft, but I also think that's a meta-discussion that
perhaps needs to be taken up with the author of
draft-peterson-informational-normativity-00.
Best regards,
Andrew
--
Andrew Sullivan 204-4141 Yonge Street
Afilias
Dear colleagues,
On Wed, Aug 08, 2007 at 03:25:58PM -0400, Dean Anderson wrote:
On Tue, 7 Aug 2007, Andrew Sullivan wrote:
Dean, do you solicit my feedback as to what
changes would be necessary to obtain my (individual) support? If so,
I will send those remarks.
/hat
Yes, thanks
in the current working group draft, and
received no feedback in the meeting for such inclusion.
/hat
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P
of time).
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
of the room today was that most people thought we should not
add this.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1
that change, while we're doing another
draft to fix the history? By my count, there are three changes that
have to be made to address this (they'd all be changed in the same way
as the example above).
Many thanks to Stephane for his careful review.
A
--
Andrew Sullivan 204
.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
what you wanted, and also gets rid of the
transport protocols nit that Rob noted. (To emphasise, though, this
whole discussion is a nit as far as I'm concerned; I'm happy to see it
go ahead without the change. It seems like an editorial matter to me.)
A
--
Andrew Sullivan
On Mon, Jun 25, 2007 at 03:14:14PM -0400, Andrew Sullivan wrote:
Issue 17: the term in use in section 4.2 is not clear.
Er, issue 19, of course. Thanks to those who pointed out just how
badly the southern Ontario heat is affecting my pea brain!
A
--
Andrew Sullivan
additional text in section 2 (Background)?
2. Can you (or anyone else) suggest a better way of phrasing the
multiple PTR paragraph to account for EDNS0 as well?
Thanks,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario
Dear colleagues,
I have entered three new issues in the tracker for this draft. Each
will be covered in threads to follow this note.
The issues are these:
- Issue 17: The term in use is not clear
- Issue 18: Need reference to RFC 1912
- Issue 19: Reference to RFC 4255 is opaque
A
--
Andrew
it may be useful to indicate that a given
range is unassigned.
I would like to include this change in a -04 submission on 2007-06-28
unless there are any objections.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
that it is an operational or
configuration error not to have matching PTR and A records.
Absent any objections, I plan to make this adjustment for a -04
submission on 2007-06-28.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
it may be useful to indicate that a given
range is unassigned.
I would like to include this change in a -04 submission on 2007-06-28
unless there are any objections.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
, why another path was taken.
Best regards,
Andrew
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
and reasoning for them is a topic for
this list.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304
would seem to be the
obvious non-action?
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
-priming-01 or any other
source.
Best,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
Extensions make DNS results
more reliable, deployment of the DNS Security Extensions in the
reverse tree will also make the reverse mappings more reliable
?
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
anyone of a point of view.
I am pleased to congratulate you on your appointment to the entry
and placement committee at MIT!
Best regards,
Andrew
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED
.
Other than that, I think this is a good and useful draft, and should
be advanced.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED
!
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
___
DNSOP
is no longer
widely viewed as helpful.)
Thank you very much for the comments and insights.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED
that reaches that threshold, I'm willing to reconsider my
view. But so far, I haven't seen one.
By the way, I apologise to all that I haven't sent the updated draft
this week; I got waylaid by another task. I hope I'll be able to
redress this either this weekend or early next week.
A
--
Andrew Sullivan
the entire thread on that topic starts here:
http://www1.ietf.org/mail-archive/web/dnsop/current/msg00042.html
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED
this way, I'd like to hear them.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
some discussion of these differences,
and also points to some considerations about tools for reverse tree
management under IPv6. If there is more you would like to add,
please send some text.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
be wrong. That's
the nice thing about a network where the intelligence is out at the
edges. Do you disagree? If so, how, and why?
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED
, so you could have a look at
them there if you'd like.
Best regards,
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
jabber: [EMAIL PROTECTED
Lewis's discussion of
the issue. I hope it is better this way.
Any comments are, as always, welcome. Thanks very much.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED
301 - 398 of 398 matches
Mail list logo
