Re: Request for community guidance on issue concerning a future meeting of the IETF
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 it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
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, that shipping addresses in application data was bad. So NodeA refers NodeB to foobar-server.sitea.org. Q.E.F.
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
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 prefix changes. That solves the problem for all apps, not just for local apps. Ah, well, if we're allowed to solve problems by fiat, let's just declare that everyone do the right thing about site-local addresses, automatically drop unauthorized packets, end hunger and violence, and brush their teeth.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
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 to count 102 hands.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
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 of handling scoped addresses in applications. At the end, the tally shows 20 hands rising in support of site locals, 102 hands rising for their elimination. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. How many of your 22 speakers had implementation and deployment experience to report?
Re: IAB policy on anti-spam mechanisms?
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 client to say prove to me that you are authorized to provide the SMTP service associated with DNS name foo.com. or did I just forget that feature? 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. (In some cases, you might want to repeat that information after the stream is protected.) The problem is that popular existing protocols don't do that. Look at the contortions you have to choose among to support HTTPS virtual hosting.
Re: IAB policy on anti-spam mechanisms?
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 unrelated domains. And remember ... Ah, that. Well, we live in different PK worlds. Yours is much larger and more congruent to plaent earth. Mine is a bunch of science labs and universities that nearly know each other.
Re: IAB policy on anti-spam mechanisms?
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 that issued its certificate is misplaced./irony
Re: IAB policy on anti-spam mechanisms?
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. Not quite inherent -- if you verify against a SubjectAltName dNSName you can decide the certificate is valid for many domains. Like I said earlier, if you want to have some set of certificates vouching for MX records, then you want DNSSEC. But I agree with this.
Re: Bind 9 AXFR Modification vs AXFR Clarification
Set the clocks correctly, and schedule the change on all the servers for a particular time, using (for example) the tinydns timestamp feature described in http://cr.yp.to/djbdns/tinydns-data.html. When that time rolls around, all the servers will change their data simultaneously, My friend Dr. Einstein would like a word with you about your casual misuse of the word simultaneously. __ Matt Crawford [EMAIL PROTECTED]Fermilab
Re: Bind 9 AXFR Modification vs AXFR Clarification
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 Honeyman In the original, $X was bound to USENET, not IETF.
Re: Searching for depressing moments of Internet history.....
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.
Re: namedroppers, continued
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.
Re: Does anyone use message/external-body?
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 hope that lays your questions to rest.
Re: Multihoming in IPv6
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
Re: [isdf] RE: Palladium (TCP/MS)
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 that's signed, not the full data. OK, if you want to be pedantic. ;) However, let's remember that although a hash collision is *possible* to generate, ... My point was not about hash collisions, but rather that the dongle that holds the key often has no idea at all about the meaning of what was signed. And if it's an intruder who caused the signing, there may be no record of the cleartext. If it was a certificate, you can't revoke it because you don't know its serial number or anything else[*] about it. Matt [*] Well, if NameConstraints were implemented you could put a bound on the Subject. That's not much comfort.
Re: MBone
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 ARP replies to Alice on port Y and Bob on port Z, telling each that the MAC address corresponding to their intended peer is that of Eve's machine. It works even if Alice and Bob are both on port Y.
Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
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, of course, a major security hole... Gee, if only ARP's funcntion was performed above the IP layer somehow ...
Re: Speaking about experiments in a live network...
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?
Re: TCP Checksum Interoperability
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 791 if they happen hold a packet more than a second, and (B) IPv6 invalidated TCP's correctness by defining the Hop Limit field to be a hop limit and have no connection to time. A TCP riding on IPv6 may receive old segments an unbounded time later without any other network element breaking a spec. I said so at the time, but nobody cared. No doubt Vint will take care of multi-second hops for us.
Re: I-D ACTION:draft-etal-ietf-analysis-00.txt
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 to be. What's all the fuss?
Re: Sponsorship (was Re: IETF Meetings - High Registration Fees)
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.
Re: Sponsorship (was Re: IETF Meetings - High Registration Fees)
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 hallways of *THIS* IETF will be a BOF at the *next* one, and a working group at the one after that. You've said that you don't go to meetings, so I won't fault your naivete, but the bulk of the hallway and bar work consists of squashing, not originating, WG items.
Re: PPP
DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 271828
Re: Vernon Schryver
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 'til the paper bag rips -- he'll be in for a shock!)
Re: Plenaries at IETF 53
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 that helps to undermine Friday's status as a real working day. In most cases, Tuesday noght could have been used for a plenary with no adverse impact to the IETF at large.
Re: Blue Sheet Etiquette
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 harvesting attack, my favorite idea (perhaps for no better reason than because its mine) is peel-off numbered (or bar-coded) labels on the backs of the badges, to be affixed to the blue sheet. The secretariat, of course, would have the number-to-name mapping.
Re: trying to reconcile two threads
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 address. Not even any old address that has been properly assigned to me. I can only use addresses that come from one of my ISP's aggregates. And with respect to that kind of address, my ISP is a monopoly supplier.
Re: Cable Co's view: NAT is bad because we want to charge per 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 accessing common web-based consumer applications on a single host violates their letter!
Re: Printing Internet Drafts
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?
Re: Deja vu all over again (53rd IETF)
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.
Re: Carrier Class Gateway
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 negligible. And outside the locks, any ship that fit through the locks will not block other traffic that also fits through the locks. (But I sure am glad I didn't send an answer to the What is Unused Dairy Product Helper question.)
Re: Carrier Class Gateway
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.
Re: bandwidth (and other support) required for multicast
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 for Solaris?
Re: Deja Vu
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 lower accommodations price, the break-even point for me is a 50-day or longer meeting. I think not.
Re: MIME Format
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 than most of us speak French. Or better than most of us know English: Main Entry: man 1 a (1) : an individual human; especially : an adult male human... b : the human race : MANKIND c : a bipedal primate mammal (Homo sapiens) that is anatomically related to the great apes ... 2 a : INDIVIDUAL, PERSON a man could get killed there b : the individual who can fulfill or who has been chosen to fulfill one's requirements she's your man
Re: I-D ACTION:draft-many-gmpls-architecture-00.txt
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 incredibly short of the state of the high energy physics "art", the difference is like NCP and IPv6 address space. http://www-cdf.fnal.gov/top_status/prl_cdf.ps or http://www-d0.fnal.gov/www_buffer/pub/pub001_dzero_detector.ps
Re: Short sequences (Re: An alternative to TCP (part 1))
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.
Re: Eliminating Virus Spam
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. Sometimes I have made the file a content/external-body to avoid stuffing O(100kB) into many mailboxes where it wouldn't be wanted. You said "this list", but the above scenario would apply if the document were pertinent to a BOF or brand-new working group.
Re: NATs *ARE* evil!
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.
Re: NATs *ARE* evil!
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 we drop that particular line of taunting?
Re: What is the IETF? -- A note of caution
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 representatives, but as individuals He also introduced the ADs as "name from employer" after the IAB had been introduced solely by name. Throw the bum out! :-)
Re: Internationalization and the IETF (Re: Will Language Wars Balkanize the Web?)
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.
Re: How many cooks?
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 perspective, look at some of the high energy physics papers that come out of THIS laboratory!
Recruiter spams nomcom volunteer list. Film at 11
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
Re: getting IPv6 space without ARIN (Re: PAT )
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 are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. Those who fail to learn from history... Or from the present ...
Re: Deployment vs the IPv6 community's ambivalence towards large providers
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") ... and you now want us to believe that you're upset by being told that you're wasting our time? There are people who play the "troll" game a lot better. They practice it in various newsgroups. Occasionally they've tried to bring it to the IETF list, to nobody's satisfaction. Maybe you'd enjoy playing in their sandbox. Go, make us proud.
Re: Sequentially assigned IP addresses--why not?
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 with that. Host names, and a means for translating them to addresses, existed before DNS. Introduction of hierarchical naming and DNS let the maintenance of this translation mechanism be decentralized. Hm, wasn't this thread started by a suggestion that so-called addresses be assigned under centralized control?
Re: Sequentially assigned IP addresses--why not?
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.
Re: Heard at the IETF
Also heard at the IETF: In the plenary session the chair denied the existence of Ireland.
Re: Domain name organization recommendation
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, with all those three-letter TLDs competing with it? Hm? Case (and plaintiffs) dismissed. [EMAIL PROTECTED]
Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
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. http://www-numi.fnal.gov:8875/overview/overview.html http://www.hep.anl.gov/ndk/postscript/numil337_3.pdf (page 5) http://www-numi.fnal.gov:8875/fnal_minos/physics/Superposition1.html http://www.hep.umn.edu/minos/images.html
Re: fyi.. House Committee Passes Bill Limiting Spam E-Mail
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 against sending "profane content" by people who obviously don't know the meaning of "profane".
Re: Acronims' ambiquity
* '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 to futureproof than to pastproof.
Re: asynchronous audio conferencing at www.wimba.com
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 signed to reassure you of its authenticity and safety. You can trust our applet. with their terms of use: c.ANY MATERIAL DOWNLOADED OR OTHERWISE OBTAINED THROUGH THE USE OF THE SERVICE IS DONE AT YOUR OWN DISCRETION AND RISK AND THAT YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR COMPUTER SYSTEM OR LOSS OF DATA THAT RESULTS FROM THE DOWNLOAD OF ANY SUCH MATERIAL. d.NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM WIMBA OR THROUGH OR FROM THE SERVICE SHALL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THE AGREEMENT. 15. LIMITATION OF LIABILITY YOU EXPRESSLY UNDERSTAND AND AGREE THAT WIMBA SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES, INCLUDING BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS, GOODWILL, USE, DATA OR OTHER INTANGIBLE LOSSES (EVEN IF WIMBA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES), RESULTING FROM: (i) THE USE OR THE INABILITY TO USE THE SERVICE; ...
Re: interception proxies
Dick St.Peters says: Quoted from RFC791, the IP specification, in the section on loose source routing, page 19 [emphasis added]: If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address REPLACES THE SOURCE ADDRESS just used, and pointer is increased by four. ... An end-to-end-inviolate source address is not a required part of the IP spec. If you look upward two paragraphs from the part 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[EMAIL PROTECTED] Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces."
Re: I-D nroff macros
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
