On Sep 18, 2009, at 10:42 AM, Marshall Eubanks wrote:
We are therefore asking for input from the community by two means - by
commenting on the IETF discussion list, ...
I'm trying to imagine the thought police remaining calm during a
plenary such as the one at Danvers. I can't quite picture
Let's assume that there is a FooBar server in SiteA. If another
node in SiteA (NodeA) is communicating via a multi-party application
to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
server in SiteA, what does it do?
I thought we agreed, completely outside of IPv6 concerns,
All right, how do you make internal site communications completely
oblivious to a change in your externally-visible routing prefix?
You declare that any app that keeps connections around for more than
some time period T (say for 30 days) have a mechanism for
detecting and recovering from
I suspect that most people there, who voted for
the elimination ...
At my first IETF meeting I received a T-Shirt, courtesy of Marshall
Rose, I believe, that said We reject kings, presidents and voting...
The real tragicomedy of this situation is that someone considered it
fitting and proper
Yes, there was mention of site local as a license to NAT, but
there where many other arguments: leakage through IP, DNS or
application; the lack of practicality of several restrictive models
for site locals; the possibility or not to use other solutions for
isolated sites; and the complexity
I see your point. But I suspect it illustrates a significant
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
that an IP address and port number are used by only one named service.
It's been awhile since I looked at the TLS protocol but I don't recall
any way for the
Not quite inherent -- if you verify against a SubjectAltName dNSName
you can decide the certificate is valid for many domains.
Yes, this is true in theory, but I want to know how you're going
to get VeriSign to issue you a certificate with subjectAltNames
corresponding to a bunch of
There's no reason a protocol can't be spec'd to let the client convey
the name of the resource before the TLS handshake begins.
no, there isn't. but it still wouldn't give the client a way to verify
that the server is authoritative for that domain.
ironyIf it isn't, your trust in the CA
Not clear. SMTP can relay a single copy of a message to multiple
recipients at multiple domains. Your suggestion would force a
separate TLS session, or a separate SMTP session, for every distinct
recipient domain.
Yes, that's true, but that's inherent in the one certificate
model.
Dr. Einstein would like a word with you about your casual
misuse of the word simultaneously.
__
Matt Crawford [EMAIL PROTECTED]Fermilab
draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc.
March 2000
Seems to be 3 years ago.
I remember when people thought OSI protocols took too long to
standardize... :-)
$X is a slow-moving parody of itself. -- Peter
An interesting subject for a thesis:
The Porn and The Internet.
Sub-titled The Beauties and The Beasts ?
Watch it. One fuzzball joke and I am outta here.
Does anybody have a reference on an authorization scheme that
doesn't imply any authentication?
You will deliver the satchel to the one who presents the matching
half of this hundred-euro note.
However, this raises a question: does *anyone* use external-body in
association with I-D announcements?
I access new I-Ds and RFCs through the message/external-body subparts
of the announcement, and I sometimes send out documents of my own
(not always IETF-related) using the same mecahnism.
I
Just how fully worked was IPv6 when the IETF picked it?
I clearly remember ipng area directors barging into wg after wg
exhorting them to ship whatever they had done, and never mind
the rest. We can always fix it when we go to draft was the
rationalization of the complaisant
No. You can trace back to the fact that the signed data was at the same
^
a hash of
place as the private key, at the same time.
I've seen people *who operate CAs* lose sight of the fact that it's
the hash
Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep up a steady stream of
On Sat, 20 Jul 2002 10:41:02 +0900, Jun-ichiro itojun Hagino [EMAIL PROTECTED]
said:
therefore, it is unsafe to transmit ARP_REQUEST with spoofed IP
source address - it will overwrite ARP entries of neighbors.
(He meant sender address, of course)
Valdis Kletnieks said:
This is,
Since the most frequent SSID is pulver.com, I interpret this as
the knife dripping with blood (but then Jeff could still be
innocent even if the knife is engraved with his DNS name :-).
You mean, it could be a case of media-layer FRAMING?
and RFC791 claims ttl is in seconds, ergo I don't have to decrement
ttl because I know my traffic is on paths less than a second
long.
Cool reasoning.
You lose -- 791 says you have to subtract at least 1 from TTL even if.
However, I think that (A) most or all extant IPv4 routers violate
however, it may be useful for folks to actually read the draft
before making comments... thus far, i've only seen two folks with
comments who claim to have actually read the thing.
OK, here's a new data point: I read it all and I have no comment. It
is neither more nor less than it purports
essentially all of the work done at meetings happens in the hallways,
restaurants, and bars - when small groups of people get together ...
Yes, I see. So much for the myth of an open process.
essentially all of the work done at meetings happens in the hallways,
restaurants, and bars - when small groups of people get together ...
Yes, I see. So much for the myth of an open process.
I'm willing to place bets that a *very* large chunk of things
accomplished in the
DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP=
=20suite?/FONT/DIV/BODY/HTML
Layer 271828
Don't feed the troll If he'll believe that gravity is an illusion
caused by neutrinos pushing in from space
( http://amoureternalcom/oti/gravity/page1htm )
he'll believe anything Anything, that is, except the voice of
reason Which as *we* all know, is seldom found OnTheInterNet
(Just wait
I think two plenary's is a good idea.
If we seriously used the time on friday, thus making thursday
night more legitmate to schedule staying in town, that would help.
also would mitigate the horrible double booking of wg meetings
I think devoting Thursday night to a plenary is one factor
IEEE 802.11 / 802.15 meetings have solved this by attaching a helium
ballon to their equivalent of the blue sheets. That way everyone can
see where they are and if they have gotten hung up.
That's a fun solution to the more general problem of slow blue-sheet
propagation. For the name
It seems to me that these two can't both be true. IP Addresses cannot at
once be scarce enough to charge for and non-scarce enough that scarcity is
a non-issue.
Does anyone else see something schizoid about this discussion?
Not I. I, as an end user or small site, cannot use just any IP
However, the fact that a customer doesn't behave according to the ISP's
assumptions does not inherently mean that the customer is stealing service -
unless the customer has contractually agreed to limit the use of his
internet service.
Have you looked at any of these ISP's contracts? Just
do away with pre-formatted pagination. rely on section numbers for
references.
Then you would keep tables and ascii-art diagrams from
being split ... how?
From http://www.ietf.org/meetings/0mtg-sites.txt:
Spring 2002 - 53rd IETF
March 17-22, 2002
Location: Minneapolis, MN
Host: TBD
We could have wished for nicer weather, but everything else went
pretty well there.
Not just a lock, but there's a bridge to worry about; passing under it
at low tide is your height limit.
i would imagine the problem would be at high, not low, tide.
oops. mea culpa.
Not at all. On a trip between oceans, waiting less than 12 hours for
a favorable tide is probably
Please suggest me place or a Document where i can get some information about
" Carrier Class Gateway".
There is no such thing. Neither the Panama Canal, the Suez Canal,
nor any other man-made waterway has locks large enough to accommodate
a modern aircraft carrier.
Open standards is a fine thing, but you have to have some implementations
and common use before it really matters. And let's not forget what the
goal was: allow people to remotely participate (for some value of
"participate").
Cool! Where can I get this free two-way interactive RealAudio
Let's see, the price is right, the convention center has plenty of room,
there are loads of hotel rooms nearby. Hmm. Sounds great!
OK, I'll bite:
Kuala Lumpur which we just used for APRICOT 2001. Five-star hotel, the Pan
Pacific $63 per night.
Let's see, with the higher airfare and
I want to give you the benefit of the doubt. So, a gentle reminder. There
are women out here too.
He doesn't appear to be a native English speaker; I doubt that he
meant to exclude women. He probably meant "people" or "folks"
rather than "men."
I expect he speaks English better
Title : Generalized Multi-Protocol Label Switching (GMPLS)
Architecture
Author(s) : P. Ashwood-Smith et al.
Wow. An I-D with 25 authors. I see we're starting to emulate the experimental
physics community!
Noel, this falls so
Is that a bit of chauvinism, Harald? :-)
D. Belsnes, "Single-Message Communication," IEEE Transactions on
Communication, Vol. TCOM -24, No. 2, pp. 190--194, February 1976.
Please point to an example of a useful multipart message seen in
this list or that might someday be useful in this mailing list.
I have sent to wg lists a multipart containing a preamble and an
internet-draft or similar file. This makes it easy for recipients to
save the draft as-is.
If DNSSEC were deployed, I see no reason why SAs could not be
bound to domain names.
Well, there are all those load-distributing hacks -- Akamai and
others. But I bet they could come up with a huge flesh-tone bandaid
so you would continue not to notice. On a good day.
What is technically wrong with v6 that isn't already technically wrong
with v4?
Thank you, Perry, you've put it in a nutshell.
Noel
Excellent. We've agreed that IPv6's problems are a subset of IPv4's.
Now until we have a concrete design proposal for a perfect world, can
But in retrospect, one thing he said bothered me greatly. He
mentioned there were representatives of some five hundred different
organizations at this meeting. That too is impressive. But it's
that word "representative" I find disquieting.
We are here not as corporate
If the world had asked you or me to design an international
language, I think either of us would have done better.
Don't be too sure. Even today, there are no more speakers of
Esperanto than of Mayan.
Is the IETF now competing with scholarly journals in the race for
``most authors on a single paper''? (No offense intended to the
parties listed above, but you'll pardon me if I get a little
uncomfortable with the idea of a 29-page document having 26 official
authors.)
Relax. For
Dave Andersen [EMAIL PROTECTED], on behalf of "Nexsi
Corporation", has sent unsolicited job-recruitment spam to addresses
apparently gleaned from the posted IETF Nomcom volunteer list.
Form your own opinion. You can guess mine.
Matt Crawford
What'd be better is for SOME organization, perhaps IANA, setting up one
provider-sized block of addresses for early adopters to USE.
Hey, great idea! RFC 2471:
This document describes an allocation plan for IPv6 addresses to be
used in testing IPv6 prototype software. These addresses
Consider the rather nasty attitude in response to my
technical deployment and utilization-scenario related
Sean, you knowingly and deliberately wasted people's time all week
with your nonsensical suggestions (as evidenced by your first
message's label "Fuel for the B Ark") ...
Phone numbers have moved from being direct as originally implemented
to being a level of indirection, thanks to a lot of behind-the-scenes
mucking about. The Internet introduced DNS to gain that same level of
indirection. Phone numbers are now portable; DNS names are portable.
I don't agree
Does this mean that every router will have to handle 2^48 routing table
entries and that this vast amount of information must be sent over the
internet on every routing table update?
Salavat
In a word, no.
In two words, Hell no!
See RFC 2374.
Also heard at the IETF: In the plenary session the chair
denied the existence of Ireland.
Its already set up link that, Not that I can ever recall seeing a .us.
you have now.
- Bill
And what was that nonsense they were spewing about www.state.us?
And if .us is "unusable", how did it get to be the third most common
country-code domain,
Did the IESG depricate IP over Avian Carrier when I blinked?
And the draft on IP over seismic waves is due any day now.
Consider the possibilities of a neutrino beam -- no media costs and
lower latency than direct point-to-point fiber.
actually I'd settle for well-defined mandatory labelling - at the SMTP
level for big volume spammers and at the 822 level for everyone.
Perhaps a future First Lady Tipper Gore will try to help you out
there, as she did for the consumers of recorded music.
Around here, we've been warned
* 'RFC editor publishes' argument becomes less quibbly and arguably
* more futureproof.)
The RFC Editor agrees with the futureproofing, ...
folks have them buried in scripts, and pragmatic continuity is more
valuable to the IETF membership than quibbling.
In other words, it's easier
As a linguistic exercise, you might reconcile this message, which you
get when you refuse to grant their applets read/write/delete/execute
access to all your files:
In order to run the Wimba forums application, you will need to
grant our applet a certain number of privileges. Our applet is
you quoted, you'll
see that "source address" does not mean the first address in the
fixed part of the IP header, but the address in the "route data"
provided by the source.
______
Matt Crawford
Alan,
I'll send you my internet-draft nroff macros under separate cover.
(There's probably some internet obscenity law forbidding the
unsolicited transmission of nroff source.)
Matt
57 matches
Mail list logo
