eading back into the recurring debate about separating
locators and identifiers... Too bad it's probably too late to add that into
IPv6.
S
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS
ertainly interesting in its own right, what I think DARPA (and
the IETF) is looking for is something between the network and transport
layers, not something above transport.
S
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Smart people surroun
Thus spake "Scott Michel" <[EMAIL PROTECTED]>
> On Tue, Mar 16, 2004 at 07:09:12PM -0600, Stephen Sprunk wrote:
> > When you add in the (assumed) requirements of backwards compatibility
> > with existing routers and hosts that don't implement a proposed
ext
TLD, and adding
one ignores existing, logical solutions.
Likewise, there is no reason for a .mobi TLD; either mobile clients should
use the standard "http" method to negotiate the content/format/encoding with
servers as needed via HTTP's existing mechanisms, or if necessary a new
m
alternative.
> I don't think you understand the proposal for the TLDs. .mobi is not for
> mobile _clients_. Its for mobile _Companies_
Equally bad, just for different reasons...
.tel and .mobi are exceptionally bad in combination since the two would end
up with nearly the same content
d for use in
situations such as this.
It's probably going too far to require sending mail from those aliases;
despite Dean's faults, he's smart enough to use the published alias if he
gets a bounce from someone's personal or work address.
S
Stephen Sprunk "Those peop
Thus spake "David Kessens" <[EMAIL PROTECTED]>
> On Fri, Jun 18, 2004 at 07:28:40PM -0500, Stephen Sprunk wrote:
> > While I disagree with Dean in general and also with most of his current
> > argument, I think it is a reasonable request that IETF "officials&qu
you calculate the
training cost of millions of MCSEs and CCNAs that don't know anything about
IPv6 and see no reason to learn.
I predict things will continue roughly as they are now, and when the IPv4
space is approaching true exhaustion the prices of PI and PA space will rise
so much that
ew years away from users not having phone numbers at all, but rather SIP
URIs that look the same as email addresses. Users don't like numbers, and
they shouldn't be expected much less forced to remember tham, particularly
long ones.
S
Stephen Sprunk "God does not pla
dial-up still are analog and now ISDN
costs _more_ than DSL or cable for low-end data.
That's just ridiculous.
But that's the situation in the US... DSL/Cable are significantly cheaper
and faster than ISDN, often by a factor of 10x or more per kbps.
S
Stephen Sprunk "God doe
The IETF has a well-defined model
and definitions for names and addresses, and you are willfully ignoring
those definitions to hide the fact your arguments make no sense.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an invete
Thus spake "Kai Henningsen" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Stephen Sprunk) wrote on 20.11.04 in
<[EMAIL PROTECTED]>:
ISTR that the local competition (the one who's laying down cables like
crazy, pretty much every time a street is dug up)
That's al
s to shoot themselves in the foot, it's not
your duty to prevent them, because they might have a perfectly good reason
to.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler,
oss ASes. Or perhaps we'll find a way to route based on ASNs in
the DFZ, and the mapping from destination IP to ASN will be made only at the
edge of the DFZ.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, a
nnels, etc. as appropriate. Of course, if my
monopoly broadband provider were to wake up and offer native IPv6, I'd want
real IPv6 connectivity...
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He
an RIR has denied
a request that met with their policy requirements. One may argue that the
policies have unreasonable requirements, but those policies were approved by
open process involving the community they serve and (for IPv4) based on the
global consensus supporting RFC 2050.
S
Stephen Sprunk
to codify such details in the BCP even if we
could. The BCP overall has evolved a tone of general guidance and public
oversight, not micromanagement, and that seems appropriate here too.
S
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Sm
icipate if the
venue doesn't have sufficient bandwidth to support streaming the meeting.
> It would also assist with focusing on the issue of increasing
> broadband uptake and opportunities. It would certainly be a
> good PR exercise.
It's not the goal of IETF meetings to
hosted by someone, let's not expect them to
> provide the terminal room.
I don't think the host should be providing PCs, but IMHO a place to sit with
a wireless laptop (and recharge it) and print out the occasional document is
underrated. Wired connections for laptops are debat
dress, so only 64k clients are possible. Other servers may be
behind a webmail application, with the same effect.
The number of folks experiencing this has to be pretty low, but it'd be a
severe problem for them.
S
Stephen Sprunk "Those people who think they know
world today.
Not that it's an excuse to _require_ middleware in protocols, but we need to
design with the knowledge that they _may_ exist.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
ivial number of schools offerring degrees in network engineering,
systems engineering, software engineering, etc. I (and many others) will be
lobbying to have the exemption repealed.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a
gies that will always
re-merge the balanced traffic further upstream.
[2] I have seen misguided operators set MTUs below 200 bytes, but my
position is that these people deserve what they get in such cases. We
cannot cater to deliberately broken implementations.
Stephen Sprunk
rendering of their name. Any
other output versions should be optional and explicitly non-normative.
Input forms should remain the same as today plus optional UTF-8. I think
that's about as "progressive" as we'll likely build consensus for any time
soon. The bad artwork t
als, and
Market Center Station is a half-mile or so from the Anatole). The train
fare is a paltry $2.25 for the trip, though, versus about $35 for a cab.
S, Dallas resident
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Smart people surr
SDRAM, etc.). We'd have to seriously
screw up to run afoul of today's limits, and the vendors can easily raise
those limits if customers demand it (though they'd much prefer charging
$1000 for $1 worth of RAM that's too old to work in a modern PC).
S
Stephen Sprunk
initely suffered from that problem. The
folks who designed IPv6 might also have suffered from it, but at least they
were aware of that chance and did their best to mitigate it. Could they
have done better? It's always possible to second-guess someone ten years
later. There's also ple
r of available addresses. So it might look like 2^128
addresses, but in reality it may be 2^40, or some other very small
number, depending on how much information you try to encode into the
address.
Again, the current identifier/location conflation combined with the routing
paradigm leaves us
eal
consumers). If anyone knows of one, please let me know off-list.
S
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
how completely bloated
IETF specs may get if we allow complicated diagrams in the PDF (or whatever)
version but don't require them in a normative ASCII version too.
S
Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround t
About the only argument I've read to date that makes sense is to allow UTF-8
to access characters that do not exist in ASCII, such as for authors' names
or better line-drawing characters. Everything else seems to fall into the
"our specs aren't as pretty as other SDOs' s
n get PIv6 space. ULA Central does
not solve any problems that the existing tools already solve, and it creates
new problems of its own.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those
Thus spake "Stephen Sprunk" <[EMAIL PROTECTED]>
ULA Central does not solve any problems that the existing tools
already solve, and it creates new problems of its own.
That should be "don't already solve".
S
Stephen Sprunk "Those people who t
has to do
stateful inspection and either drop the packet or forward it without any
mangling at all?
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS
u may never see two connections using the same IPv6
address and have to block a /64 at minimum for blacklists to have any
effect. Fortunately, that's entirely compatible with most deployment
scenarios, as each customer will be on their own /64 (or shorter).
S
Stephen Sprunk "Those p
allows us to drop v4 sooner, it's that much sooner
app developers can stop paying that cost, and that's good for everyone.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to thos
Thus spake "Keith Moore" <[EMAIL PROTECTED]>
Stephen Sprunk wrote:
Thus spake "Keith Moore" <[EMAIL PROTECTED]>
NAT-PT really needs to be wiped off the face of the earth. It
provides all of the disadvantages of IPv4+NAT with all of the
transition costs of IPv6
thod to get there from where we are today. I think that NAT-PT is no
less evil than the v4 NAT we're using now and will get us to a NAT-free
v6-only Internet faster than other strategies proposed. The shorter the
transition is, the better things will be for all of us in the end.
S
d of, say, their spouse
sniffing their credit card numbers at home than the NSA and FBI tapping
their email and web browsing at the CO?
Sorry, but that's the wrong response to the wrong problem.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #372
PI) has become mandatory in the US for
public corporations, though I've never seen a citation.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
on't have Internet service.
ARIN policy, at least, explicitly allows for direct assignments to end sites
even if they're not connected -- just like IANA assigned Class A/B/C blocks
to disconnected orgs back in the good ol' days.
S
Stephen Sprunk "God does not play dic
f legitimate routes that having
PI causes. However, without PI, there would be no routes at all because
IPv6 would be ignored. PI is, unfortunately, the lesser of two evils.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate g
I space by pretending to be an
LIR. The world must look a little different when the rules you're a
proponent of magically don't apply to _you_.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler
ted
to the public Internet or any ISP -- to exchange bits with each other
reliably. Those folks generally do not participate in the IETF/RIR process,
so many forget they exist.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is
litical problems, but telling people that change control processes or
security rules are "wrong" is just going to get you ignored.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws th
unhappy with the policy or need a better explanation, please join
[EMAIL PROTECTED] and ask for help. If you do not believe ARIN is following the
existing policy, please contact [EMAIL PROTECTED]
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]>
> From: "Stephen Sprunk" <[EMAIL PROTECTED]>
> _understand_ why PI is necessary, however much they dislike and/or
fear
> it.
Most (all?) of us understand and accept that multi-homing, ve
hose things are broken, of course. That doesn't change the fact
they exist and folks in the operational community will not be impressed with
a "solution" that ignores those problems.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723
bility.
Since some RIRs have PI, the odds of that happening have been reduced (which
was a major motivation for PI being accepted), but many folks who are asking
for ULA-C/G are ones that do not qualify under current PI policies and/or
are served by RIRs that haven't adopted PI at all.
S
Ste
iently told vendors that they
should not wire specific prefix lengths into hardware, so this hasn't
resulted in any problems like we saw when CIDR was introduced.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveter
hority the IETF has over address
policy. I also fail to see why the IETF thinks it _should_ have any
authority over that or any other operational matters. In my view, the IETF
develops tools and it's up to operators to determine if/how to use them.
S
Stephen Sprunk "G
arently feel
free to declare the IETF's guidance not "rational", to use your word, and go
out on their own when needed to meet the community's needs. There is a key
difference between advice and authority.
S
Stephen Sprunk "God does not play dice.&quo
ay. The financial results are
predictable for both, as is the community that each is responsible to: the
IETF caters to vendors and the RIRs to operators.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler,
s they have TFTP ALGs, but I doubt it
given they can't even handle FTP or DNS right in many cases.
I agree NA(P)T is an evil hack, and I'd love to see it go away, but this is
not a valid example of its evilness.
S
Stephen Sprunk "God does not play dice." --Albert
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 19-sep-2007, at 16:40, Stephen Sprunk wrote:
[provider independent addresses]
However, it is the only solution available today that the operational
folks consider viable. The IETF promised something different and has
the massive deaggregation done by the bigger
players due to some combination of TE and incompetence.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportun
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 20-sep-2007, at 18:33, Stephen Sprunk wrote:
ARIN's counsel has told ARIN that it is unclear if they have legal
standing to revoke legacy assignments.
First of all, litigation isn't the only way to get someth
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 19-sep-2007, at 17:48, Stephen Sprunk wrote:
All of those things are broken, of course. That doesn't change the fact
they exist and folks in the operational community will not be impressed
with a "solution&qu
ework of TCP and most TCP stacks, which means it's at least a
decade away. What are we supposed to do until then?
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inve
should have happened by 1998 or 2000 -- not 2007.
NAT-PT was a reasonable solution to this (with a few tweaks), since it could
make hosts _appear_ to be dual-stacked with little effort, but it offended
the purists and was killed despite there being nothing to replace it.
S
Stephen Sprunk
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 20-sep-2007, at 21:10, Stephen Sprunk wrote:
First of all, litigation isn't the only way to get something done, and
second, do don't know that until you try.
If you try to revoke someone's /8 or /16,
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 20-sep-2007, at 21:19, Stephen Sprunk wrote:
Sometimes ignoring a problem really does make it go away.
Install a workaround, on the other hand, and the brokenness
remains non-obvious so it persists.
If often persists wh
we can,
though, and if you wish to contribute please subscribe to PPML (and read the
archives to get up to speed).
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at e
if the folks hadn't been so dogmatically against NAT at the time,
the v4-to-v6 transition model would have worked similarly and we'd be done
with it by now...
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveter
ht years ago. If one doesn't like the name that was picked,
perhaps because it's confusingly similar to names of other things, the time
to correct that is long past.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is
NAT-PT box at a content site that allows remote IPv6-only hosts to access
local IPv4-only hosts. (And ditto for reversing the versions for each
case...) We may need to distinguish between roles, because the expectations
and configurations will differ, but the core technology and
protocol-mang
Thus spake "Keith Moore" <[EMAIL PROTECTED]>
> > The list moderator asked him to add his email address to the list, and
> > indicated that as a result of doing so his mail would be unmoderated. Is
it
> > so hard to do?
>
> frankly, it's ridiculous to expect people to subscribe to every list to
whic
Thus spake "Michael Froomkin - U.Miami School of Law"
<[EMAIL PROTECTED]>
> I have just run into an example of this (POISSON) when I was unable to
> find the archive. I was surprised -- and puzzled. Surely the storage
> costs for archiving ALL IETF lists, especially in their spamless form,
> can'
Thus spake "Marc Schneiders" <[EMAIL PROTECTED]>
> Since .com was running _on_ the root-servers.net until recently
> without problems, what are we talking about?
>
> Naturally there won't be 1 million TLDs all at once. We could start
> with a couple of hundreds. That would merely double the size of
Thus spake "Dean Anderson" <[EMAIL PROTECTED]>
> I would agree the problem is solved if Bush adds the proper addresses to
> the approved subscribers list, as publicly requested.
>
> But since it has taken so much discussion to arrive at that solution (and
> I'm not sure we have yet), list managemen
Thus spake "Joe Baptista" <[EMAIL PROTECTED]>
> I disagree. The current arrangement of increasing registrars looks alot
> like a multi level marketing scam. Basically the goal is to squeeze every
> penny out of the dot.com universe. It' don't wash.
>
> Users want *.choice in their tlds. The who
Thus spake "Eric A. Hall" <[EMAIL PROTECTED]>
> on 12/2/2002 11:13 AM Stephen Sprunk wrote:
>
> > Okay, so when every foo.com. applies to become a foo., how will you
> > control the growth?
>
> 1/ no trademarks allowed
Every combination of characters
Thus spake "Einar Stefferud" <[EMAIL PROTECTED]>
> In case you have not noticed, one possible solution is to eliminate all
> TLDs other than .COM, which is the only one that you say so may people
> believe exists.
>
> At which point someone will notice that all addresses have a
> redundant .COM (be
Thus spake "Mark Harris" <[EMAIL PROTECTED]>
> Being relatively new to IETF discussions...
>
> I have a few questions concerning your comment:
>
> When over a dozen people make comments of interest, regarding a topic on
the
> list, would it not seem that some people are not tired of it?
>
> What is
Vernon Schryver wrote:
> It's been years since it was possible to be amused by the number of
> people who assume that spammers are more ignorant and less competent
> than they are, and so propose spam "solutions" predicated on spammers
> being unable to register as many names, keys, identities, or
Paul Vixie wrote:
>> - many ISPs won't let you forward or submit mail through someone
>> else's SMTP server, even if you have permission to do so. so you
>> can't forward your mail through your "home" ISP's mail server to
>> allow the "mail from" check to work.
>
> in that case you'd be wise
Thus spake <[EMAIL PROTECTED]>
> Authentication: Yes, you seem to be Jeffrey Dahlmer.
> Authorization: You say you'd like to borrow a steak knife?
>
> Usually clears up the confusion in all but the most sluggish mind.. ;)
That's a very clear example, thanks.
> However, "authorization" usually
Thus spake <[EMAIL PROTECTED]>:
> On the other hand, if Olafur is in fact making a living doing BIND9
> development and coding for ISC or one of their clients, that might be
> called a "conflict of interest" when the issue at hand is that a specific
> document is "too BIND9 specific".
>
> Personall
be able to get portable IPv6 addresses?
. How would you like to renumber your entire network every year?
. How would you like us to sell you IPv6 NATs so you'll never have to
renumber again?
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 &
you are correct in one
sense. What I am seeing is debate over private address space and NAT, which
many of us had expected site-locals to be useful for -- this email thread
(and the one on routing-discussion) belies any claims of consensus on that.
S
Stephen Sprunk "God does not play
different engineering model than the public
Internet.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
ted turns people off.
Perhaps those folks should use an implementation that can manipulate mail
offline and then sync with the server later.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws
- with no trust
> roots implied -- could help?
It does, at least until spammers start signing their email too.
Does my signature on this message make you trust it more than, say, the ten
ads you got this morning for Viagra? Why or why not?
S
Stephen Sprunk "God does not play dice.&
IME.
If I didn't worry about such problems, I'd have my client automatically sign
all outgoing email. Of course, I'm not sure whether I'd do it with PGP or
S/MIME...
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an
ck, the majority can safely speak only v4 or only v6.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
but corporate types seem to feel punishing insiders after the fact is
good enough, and prevention only applies to strangers.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
is a recipe for disaster, IMHO.
If you don't trust the owner, you have no reason to trust the machine, and a
trusted firewall is the only place left to enforce security policies.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
end which haven't
gained any momentum thus far.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
own that using channels 1, 4, 8, and 11 doesn't lead to
performance impact either; the minor overlap is not enough to cause packet
loss.
Should this move to NANOG, perhaps?
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is
; Governments have to understand that and for that dissociate themselves
> from the old telco concept...
If the Internet _were_ done in the ITU, it would look like the phone system,
and we'd still be stuck in the 1970's.
S
Stephen Sprunk "God does not play dice." --
ent PDA and webmail systems. IMHO, the problems (listed by others) with
this proposal grossly outweigh the complaints of a couple people who refuse
to use a modern MUA or can't figure out how to configure said MUA to filter
on the Sender header.
S
Stephen Sprunk "God does not pl
; http://202.114.9.200/English/main.htm
> More content will be translated in these days.
It appears your site isn't accessible many places outside CERNET/ChinaNet;
can you post your papers somewhere with better reachability?
S
Stephen Sprunk"Stupid people surround themselves wit
this month, and zero of them have "ietf"
anywhere in them, either header or body. Thus, I see no compelling reason
for the ietf's list software to sign anything when a simple MUA filter on
the Sender: line already achieves 100% accuracy.
S
Stephen Sprunk"Stupid people s
Folks,
I think this thread has deviated enough from its original intent that the
best place to continue it is on the ASRG list -- there's no point in
bothering the entire IETF with yet another anti-spam discussion.
S
Stephen Sprunk"Stupid people surround themselves with smart
her, it's our job to determine how to make that
technically feasible and (hopefully) efficient.
S
| | Stephen Sprunk, K5SSS, CCIE #3723
:|::|:NSA, Network Consulting Engineer
:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX
.:|||:..:|||
sing here, or else this would have been
implemented 15 years ago... Thoughts?
S
| | Stephen Sprunk, K5SSS, CCIE #3723
:|::|:Network Consulting Engineer, NSA
:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX
.:|||:..:|||:.Email:
a bit dated, Henning Schulzrinne and Jonathan Rosenberg's paper
has quite a bit of detail on the subject:
http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.ps.gz
> Masataka Ohta
S
| | Stephen Sprunk, K5SSS, CCIE #3723
:|::|:Network Consulting Engineer, NSA
:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX
.:|||:..:|||:.Email: [EMAIL PROTECTED]
remendous
> demands. So go figure out utility and economics of IP addresses in
> wireless devices for now.
See above.
S
| | Stephen Sprunk, K5SSS, CCIE #3723
:|::|:Network Design Consultant, HCOE
:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX
.:|||:..:|||:.Email: [EMAIL PROTECTED]
be..
A reasonable degree of cynicism tells us that this will be impossible;
"secure" and "real-time" I might buy, but the state of inter-provider
cooperation will need to advance significantly before I'll believe any
Net-based service will even approach &quo
t; Internet.
Uniqueness is mandatory for any two organizations connecting together,
even if they don't connect to the Internet itself. Trying to allocate
private addresses between N parties partially meshed to each other is a
simple task when N is small, but the nature of the beast is that N
1 - 100 of 116 matches
Mail list logo
