Re: Names of standards-track RFCs
John C Klensin wrote: The expansion of it as an abbreviation doesn't provide significant information and may, indeed, add to confusion. It also makes it harder to search rfc-index.txt, since names can span line boundaries and abbrevations can't. Now, as far as I have been able to tell, everyone who has anything to do with 3GPP or its standards knows it as "3GPP". It's also reported in the trade press as 3GPP; I don't have anything to do with it, but I recognize 3GPP and didn't recognize "3rd Generation Partnership Project". -- /=========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.| \=/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: "setting up the administrative structures we need"
John C Klensin wrote: * Yes, we could cut meeting costs considerably by holding all meetings in the US [...] the US has now created an entry visa situation that makes it essentially impossible for network engineers from a number of countries to attend. How about holding meetings in Canada? It'd be almost as cheap for the US people to attend, and (last I heard) Canada didn't have visa requirements derived from the War On Alleged Terrorists Who Have Major Oil Reserves. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"If nobody believes what I say, I feel ineffective." "Oh, I don't| |believe that." | \=/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Alternative Decision Making Processes for Consensus-blocked Decisions in the IETF' to Experimental RFC
Scott Bradner wrote: might be better as: In no way should this experiment or any future BCP for this small number of cases take precendence over the IETF's normal mode of operation. Specifically, these procedures are only to be used when a working group agrees to use them. Define "agrees". When a WG is blocked on consensus for a technical issue, and someone proposes using the alternative process to reach a decision, do you need consensus to use the alternative process? If so, I'm skeptical that people who have been stonewalling each other on the technical decision are going to agree to a process that means they don't get to stonewall any more. -- /=========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"If nobody believes what I say, I feel ineffective." "Oh, I don't| |believe that." | \=/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
Iljitsch van Beijnum wrote: On 27-mei-04, at 16:56, [EMAIL PROTECTED] wrote: (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) The question is whether spammers can obtain new credentials (stolen or otherwise) faster than others can blacklist them. And, if you had actually read the message you replied to, you would have realized that the answer is yes. Send out a worm that makes N zombies, have each zombie send one message under the local user's credentials, and none of them will get blacklisted. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |The light at the end of the tunnel is a terawatt laser cannon. | \===/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: respect privacy please !
Leif Johansson wrote: Maybe I'm using an alias... I could be Jim Fleming :) Tim... Jim... the plot thickens! And the ASCII representations of "Tim Chown" and "Jim Fleming" can *both* be written as 0s and 1s! -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"What now, Brain?" "We should flee in terror. Yes, that would be| |the wisest course." | \/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: 60th IETF - Registration
Ken Hornstein wrote: To be fair ... I've certainly experienced the same thing at non-US IETF hotels (the one that sticks out in my mind is Adelaide, but I believe there were others). I remember setting my alarm for 3:00 AM to make a reservation for Oslo. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |In the country of the blind, the one-eyed man is in therapy.| \/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Dean Anderson wrote: One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. No, actually, that's very difficult for anyone to see. First off there's the simple matter that "hijacked" doesn't mean you hijacked it; as has already been pointed out, it could mean that someone else hijacked part of it from you. Second there's the fact that ARIN lists your netblock as being assigned to the Open Software Foundation (with yourself as the contact). It is impossible for an outsider to know whether or not the OSF transferred the block to av8.com legitimately. I don't suspect it, you understand--nor do I much care--I'm just pointing out that it's not plain whether anybody here is lying. -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Baldric, how did you manage to find a turnip that cost 400,000| |pounds?" "Well, I had to haggle." --Blackadder III | \===/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Dean Anderson wrote: It seems that WG co-chair has begun to use an email address that is defaming Av8 Internet, Inc How is it defamation if the only one that gets the message is Av8? -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |I'm not a bibliophile, I'm a bibliophiliac. Put me in a| |bookstore, & my wallet bleeds. | \===/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Not sure if this is the right place for this
John Rudd wrote: The problem with the STARTTLS strategy is: you can't guarantee at the network level that a client will use SSL/TLS. Guaranteeing that the client will use TLS is worthless anyway, since TLS includes the "None" encryption option. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Guide us, oh holy Lemming Herder! | \==/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Principles of Spam-abatement
John C Klensin wrote: In the Boston area, as far as I know, there are a number of consumer aDSL providers, but none of them provide fixed addresses and most prohibit servers of any sort, etc., without "upgrading" to much more costly "business services". Check out Speakeasy; they don't filter. Their basic package is dynamic IP, but you can get multiple static IPs, without going to SDSL. -- /=========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"I'm off to wander the streets aimlessly. I'll be taking my usual| |route." -- Lillith, _Cheers_ | \=/
Re: License for downloading music - well!
Dan Kolis wrote: Paypal and micropayments have been horribly remiss in not developing adiquate solutions to small payments. Check out Peppercoin (http://www.peppercoin.com), which has developed a stochastic model based on aggregating a user's payments. They're getting some traction in the legal-download sector. One of their advantages is that they don't actually perform the transaction; they just provide the software that layers on top of the merchant's existing transaction software. So the merchant doesn't incur an ongoing cost, doesn't have their relationship with the bank disrupted, and doesn't have to worry about being stranded if the micropayment company goes out of business. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Using strong crypto on the Internet is like using an armored car| |to transport money from someone living in a tent to someone | |living in a cardboard box. | \/
Re: digital signature request
David Morris wrote: It also supposes that the private keys aren't protected with a passphrase. Nope. All you need is a keystroke monitor. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |I'm not imaginary. I'm ontologically challenged.| \/
Re: digital signature request
Dave Aronson wrote: On Wed February 25 2004 09:53, John Stracke wrote: > Not necessarily. Spam viruses would then start collecting people's > private keys. Theoretically possible, but at least it would significantly raise the bar. Only one person needs to figure out how to do it. Think script kiddies. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"So we've strapped a Patriot missile onto Snorky here." "You said| |that was a PROP!" "It's a *functional* prop." -- What's New, by | |Phil Foglio. | \=/
Re: digital signature request
Dave Aronson wrote: Requiring digsigs on a list would help cut down on spammers forging list members' addies to spam "only members can post" lists. Not necessarily. Spam viruses would then start collecting people's private keys. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |How many roads must a man walk down before he admits he is LOST?| \/
Re: Do we or don't we need a visa for the Korean IETF?
Aaron Falk wrote: This is insane. Can the Secretariat please give unambiguous advice (preferably backed up by a letter from the Korean embassy) to attendees? It sounds like you might be safest contacting the Korean embassy yourself and asking for a visa. If they say you don't need one, you're on firmer ground than if the IETF says you don't need one. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |That is correct. I'm out of fuel. My landing gear is jammed. And| |there's an unhappy bald eagle loose in the cockpit. | \/
Re: Hi
[EMAIL PROTECTED] wrote: Test =) qxbavnirg -- Test, yep. I didn't write that; the return address was faked. The Received: lines show it was from an IP address assigned to the University of Sydney. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Solipsists have all the fun. | \==/
Re: Visa for South Korea
Ken Hornstein wrote: What I'm really looking for is some form of official government communication on the subject (unless of course the hosts are the ones who are manning the passport control desks at the airport). So call the nearest Korean consulate/embassy. Answering this kind of question is part of their job. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Where's your sense of adventure?" "In front of a roaring fire| |with a cup of cocoa." | \==/
Re: Hashing spam
escom wrote: I work on an approach to block spam with a database of hash (md5) string of spam email: 1) Reporting a "verified" spam to the database server on the web 2) the mail client check incoming mail, generate a hash string send to and verify the presence on the server, is yes block email. 3) download a hot list to block directly on the machine It's been done, and the spammers have already evolved to get around it: they randomize the messages so that the hashes don't match. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"No, no, that's *not* a boat, that's Queen Victoria."| \=/
Re: Adding [ietf] considered harmful
Mark Allman wrote: A tag in the subject line is clearly overdue. But, if we're going to do it, let's do it right. Please use "[IETF]" not "[ietf]" because it's more befitting of a proper acronym. Just what we need, a mailing list that SHOUTS. (Then again, for this list, maybe it constitutes fair warning...) -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Music is not a noun, it's a verb." --John Perry Barlow| \===/
Re: Tag, You're It!
David Morris wrote: Even so, any point of sending signed mail to a public list should be to allow the list to process the signed mail. That is not the only point by a long shot. A much more important goal would be to help the recipients trust that the message was sent by the person it claims to be from. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Call me a Nervous Nellie, but I am concerned about the sale of| |nuclear arms in my general neighborhood." -- Dave Barry| \===/
Re: Tag, You're It!
Paul Hoffman / IMC wrote: At 12:47 PM -0500 12/17/03, John Stracke wrote: S/MIME can sign the Subject: header (see RFC-1848, section 6.3) RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant implementation. Oh. Sorry. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Fate just isn't what it used to be." --Hobbes| \==/
Re: Tag, You're It!
Paul Hoffman / IMC wrote: At 9:55 AM -0500 12/17/03, John Stracke wrote: Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. Which digital signatures are you talking about? Neither S/MIME nor OpenPGP sign the headers in messages, only the bodies. S/MIME can sign the Subject: header (see RFC-1848, section 6.3), and probably should, since some people write messages where the subject is part of the meaning--change the subject and you change the meaning of the message. (As an extreme case: at this company, people sometimes send messages with no body at all. It's so common that they have a convention for it: they put "(eom)" in the subject line, for "end of message".) -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Collect call from reality, will you accept the--" *click*| \==/
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
Mark Smith wrote: Why should email assume fixed IP addresses for email delivery, or rather, matching PTR and MX records ? Because spammers target home users with broadband connections, and try to crack their systems to use them as open relays. As a result, some ISPs have taken this step; they figure you can always send mail via your ISP's SMTP server. Yes, it's dain-bramaged. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Never underestimate the power of human stupidity. --I forget who| \/
Re: Tag, You're It!
Dave Aronson wrote: Long story short, here's my proposal: - Tag the stuff [ietf]. Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. We're never going to get widespread use of signed email as long as we have pieces of mail infrastructure munging messages to make signatures useless. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Never underestimate the power of human stupidity. --I forget who| \/
Re: /48 micro allocations for v6 root servers, was: national security
Bill Manning wrote: % b) that it's generally agreed that all the RIR's ought % to have the same rules regarding microallocations, (b) on the other hand, has any number of legal implications... collusion, monopolies, etc. But this is a example where uniformity is desirable on technical grounds (i.e., if the policies aren't uniform, nobody will know how small they can afford to filter). That's got to be legal, or no standards body would be safe. Or do you think the participants in, say, the ipp WG are vulnerable to charges of colluding to drive competing printing protocols from the market? -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"The Reality Check's in the mail." --L. Peter Deutsch| \=/
Re: SMTP compressed protocol...
Franck Martin wrote: While talking about HTML in e-mail messages that consume a lot of bandwidth... Why SMTP servers do not negotiate to send an 8bit compressed stream between themselves. Doesn't STARTTLS take care of that? Doesn't TLS support compression, to eliminate redundancy and resist cryptanalysis? -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"The Reality Check's in the mail." --L. Peter Deutsch| \=/
Re: i18n name badges
Iljitsch van Beijnum wrote: On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. Wouldn't it be even cheaper if everyone who has a laptop with wireless with them signs in on an electronic version of the blue sheets? This just takes a few hours of fiddling with PHP and saves the secretariat probably 90% of the blue sheet processing. But would people do it? As it is now, the blue sheet comes around and you sign it; done. If the chair stood up and said, "Remember to sign in at ietf.org/bluesheet", people would put it off until it was convenient, and many would forget. If we want to reduce the cost of processing the blue sheets, we could provide each attendee with a sheet of barcode stickers. The bluesheet comes around, you put one of your stickers on it, you pass it on. Then the secretariat needs just one barcode scanner, and can probably get done faster than it takes to do data entry on the current bluesheets. The barcodes would have unique IDs; the secretariat would print up a couple thousand in advance of a meeting and save the unused ones for the next meeting. When someone registered on-site, the registration process would include scanning one of their barcodes, to build the link between barcode and name. A quick search at Amazon shows address labels, 25 sheets of 30, for $10. Give each attendee one sheet; that's 40 cents per person. Less than RFID, we only need one reader, and barcode readers are cheap. Or somebody could hack up software to do barcode recognition on the image of the bluesheet, and then the secretariat can use a flatbed scanner and scan a whole sheet at a time. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: i18n name badges
JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. How would RFID be cheaper than barcodes? Someday, maybe, but today the tags are expensive--according to CNet, "depending on volume, customers can expect to pay 30 cents to $1 per radio tag". The IETF would be low-volume, so we'd probably be paying closer to $1 apiece. So just the tags for just one meeting would cost more than a passel of barcode scanners. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: Hand drumming before tonight's plenary
Pekka Savola wrote:
On Thu, 13 Nov 2003, Spencer Dawkins wrote:
("drumming is a healing thing, in many cultures")
Isn't it after the plenary when we'll need the healing?
Depending on people's skill level, it could be after the drumming. ;-)
--
/========\
|John Stracke |[EMAIL PROTECTED] |
|Principal Engineer|http://www.centive.com |
|Centive |My opinions are my own. |
||
|A successful tool is one that was used to do something undreamed|
|of by its author. |
\/
Re: FYI: BOF on Internationalized Email Addresses (IEA)
Dave Aronson wrote: Think also of many businesses that cater to the general public, from bleeding-edge geeks like us, to those who can barely spell PDA and don't know what one is. I think the only times I've seen anybody use PDAs to exchange contact information were at IETF meetings, in the hallways, when people had time to kill. It just takes too long. Typically, when two companies are meeting, and you've got, say, four people on each side, everybody swaps business cards in under a minute, and you're done. Doing the same thing via IR would hold the meeting up too long. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |I have strong opinions about ambivalence. | \==/
Re: [Fwd: Emerging Network Usage and Engineering Issues]
NM Research wrote: My answer to your question is that I want IETF, ISO and ITU to set nuclear warfare standards, It might be useful for someone to produce such standards, but they're really not in the IETF's domain of expertise. Maybe some part of ISO would be better. The internet was not made for e-commerce, its mission was to communicate during nuclear warfare. False. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"If there's anything The Flintstones have taught us, it's that| |pelicans can be used to mix cement." -- Homer Simpson | \==/
Re: re the plenary discussion on partial checksums
Jonathan Hogg wrote: On 17/7/03 8:30, bill wrote: I would have a hard time taking an IP header bit and making it the "Do not drop this packet in the presense of a bit error somewhere in the frame from layer 2 - layer 3". Don't think it is a good idea. What if that bit got corrupted? This is a good point. If an L2 error can make a normal "discard on errors" packet come through marked as "tolerate errors", then implementing this feature can introduce errors in existing applications. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Where's your sense of adventure?" "Hiding under the bed."| \==/
Re: re the plenary discussion on partial checksums
Keith Moore wrote: so it seems like what we need is a bit in the IP header to indicate that L2 integrity checks are optional, and to specify for various kinds of IP-over-FOO how to implement that bit in FOO. How would an app know to set this bit? The problem is that different L2s will have different likelihoods of corruption; you may decide that it's safe to set the bit on Ethernet, but not on 802.11*. And, in general, the app doesn't know all of the L2s that may be involved when it sends a packet. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Linux: the Unix defragmentation tool. | \==/
Re: Multicast Last Mile BOF report
Keith Moore wrote: maybe the ISPs supporting multicast could prioritize that traffic, thus providing better service on multicast than unicast, thus providing an incentive for receivers to use multicast over unicast. This would provide an incentive to game the system and use multicast even if you had only one receiver. Isn't the real problem the fact that the set of streams that people might receive is so diverse, most links won't be carrying more than one copy of the unicast stream anyway? Multicast would help only at the sender's end, in the case of flash crowds; and the sender's ISP has no incentive to shrink the size of the bitpipe the sender needs to buy. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"But she calls her ship _Mercy of the Goddess_!" "Kali." "Oh."| \==/
Re: First Timers
Richard Perlman wrote: On 7/5/03 3:08 AM, "Ole J. Jacobsen" <[EMAIL PROTECTED]> wrote: "Casual and comfortable" is a phrase that describes us well. We favor the practical over the formal. Don't believe a word Ole says. I have seen him at many of his 50 IETF meetings and most of the time his T-Shirt has been recently washed. Ah, but wearing clean clothes at IETF is practical; it's so inconvenient when somebody walks by, gets a whiff, passes out, and trips over your power cord. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Who died and made you king?" "My father."| \==/
Re: UPNP was:RE: myth of the great transition (was US Defense Departmentforma lly adopts IPv6)
Keith Moore wrote: ] You could publish URLs without port numbers if you could count on the ] cliens recognizing SRV records. use of SRV records for apps that aren't specified to use them is a violation of both those apps' protocols and the SRV specification. Agreed. But it's an option for people who need to build new apps to kludge around NATs. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |*BOOM* "Thank you, Beaker. Now we know that is definitely too| |much gunpowder." -- Dr. Bunsen Honeydew | \=/
Re: UPNP was:RE: myth of the great transition (was US Defense Departmentforma lly adopts IPv6)
Michel Py wrote: In DNS you publish: x.y.z.t server1.example.com x.y.z.t server2.example.com x.y.z.t server3.example.com [...] That's were the coolness is; no stinkin' port number. You could publish URLs without port numbers if you could count on the clients recognizing SRV records. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"The Reality Check's in the mail." --L. Peter Deutsch| \=/
Re: myth of the great transition (was US Defense Department formally adopts IPv6)
Eric Rescorla wrote: (2) NAT solves at least some of those problems, at some cost (say Cn), both financial and operational and that solution has benefit Bn. (5) It's also possible that at some time in the future Cn will exceed Bn, in which case I would expect people to stop using NAT and (probably) demand something else. I think this is the point of contention: Keith asserts that Cn exceeds Bn if you consider long-term costs; your invocation of revealed preferences is based on the market, which tends to be short-term. Cn -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |Beware of wizards, for you are crunchy and good with ketchup.| \=/
Re: Spam
Paul Vixie wrote: if we could make spamganging so illegal that they were eventually not replaced, then their traffic would be replaced by bulk e-mail from every customer of every CRM (customer relationship management) company in the world. I'm not sure why this follows. Wiping out the fraudulent spammers would take a War On Spam, with massive levels of propaganda to stir up public opinion enough to justify the money it would cost. In that kind of environment, even in the aftermath, no white hat would dare spam; their customers would immediately turn against them. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Never do card tricks for your poker buddies.| \/
Re: A peer-to-peer trust system model
Theodore Ts'o wrote: someone who is sending me a human generated message can generally easily afford the 2 minutes worth of CPU time before their mailers can deliver the message to my mail host.) But what CPU? The machines with which I routinely send mail range from a 200MHz handheld to a 2GHz*2 desktop. I would be unhappy with a protocol that required me to run my handheld's CPU at full speed for 2 minutes (the battery life isn't so hot); but that level of hashcash would require only 6 seconds from my desktop, which is probably too little to be a deterrent. And, if it were targetted at making my *desktop* take 2 minutes, then the handheld would take about 40, which is totally unacceptable. The whole hashcash idea has two major flaws. The most obvious is Moore's Law (you'll have to keep doubling the bar every 18 months, which means email will get more and more expensive for people who don't upgrade their CPUs). The other is that all it proves is that *somebody* spent those CPU cycles. Spammers already steal resources to send their messages; what's to stop them from sending out stealth worms that use the victim's machine to do hashcash calculations? -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |There are footprints on the moon. No feet, just footprints.| \===/
Re: The utilitiy of IP is at stake here
Tony Hain wrote: it wouldn't take much to convince people that moving to a new mail system would either reduce spam, or had adequate mechanisms for financial recourse. I think you mean that, if people believed the new system would reduce spam, it wouldn't take much to convince them. It *would* take a lot to convince them that it would reduce spam; people with a normal, healthy cynicism gland (and without the expertise to analyze the new protocols) would assume that it was just a marketing ploy. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |*BOOM* "Thank you, Beaker. Now we know that is definitely too| |much gunpowder." -- Dr. Bunsen Honeydew | \=/
Re: spam
Tony Hain wrote: The protocol needs to be basic and simple, but place the bulk of the operational cost at the origin rather than the current model of placing it at the receiver. Hmm. It's pretty much in the nature of human-to-human communication that the receiver is always going to have higher humanpower costs than the sender (since it's easier to say something than to understand it); so the only way to shift the balance is to impose extra costs on the sender. In other words, any group chartered to work on such a protocol would be *required* to be inefficient. At last, a charter goal we know we can meet! :-) -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==/
Re: spam
Dean Anderson wrote: In fact, it is an axiom that crowds are always wrong. I *suppose* that's a true statement--somebody somewhere (e.g., you) must be working with "crowds are always wrong" as an axiom. But those of us who know what the word means understand that whether something is an axiom has nothing to do with whether it's true. -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Power corrupts; Powerpoint corrupts absolutely." -- Vint Cerf | \===/
Re: spam
Dean Anderson wrote: We are lucky that spammers don't get a discount Open relays give them a five-finger discount. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Power corrupts; Powerpoint corrupts absolutely." -- Vint Cerf | \===/
Re: spam
Eric A. Hall wrote: on 5/26/2003 5:17 PM Dean Anderson wrote: Junk fax law, overturned as being unconstitutional restriction on speech. You keep bringing this up. Please cite. As I said in another message, the only ruling I know of that would support this was overturned on appeal. And the court whose ruling was overturned (I read the ruling) had made the same sort of error Dean is making: assuming that the only costs involved were those of physical resources (paper or disk space). -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Collect call from reality, will you accept the--" *click*| \==/
Re: Thinking differently about the site local problem (was: RE: sitelocal addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice - often moreso than the standards themselves. Strange as I feel defending Microsoft, I actually think it's commendable that they implemented IPv6 at all; it's not as if there's a lot of market demand for it yet. From that viewpoint, it's not surprising that they gave IPv6 address literals a low priority. (Personally, I would've implemented address literals *first*, so that, if I ran into a bug, I could isolate whether it was in DNS lookup or not. Would've saved time in the long run, since debugging takes longer than coding.) -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: John Stracke wrote: Jeroen Massar wrote: Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. In any other way do you like remembering and typing over 128bit addresses?? :) :: is your friend. If you're building an ad hoc, point-to-point network, you can pick convenient addresses. :: as in all 0's which corresponds to 'not bound'? No, as in a string of 0s. If you set up your own isolated network, you can make one host be 1::1 and the other 1::2. Most OS's require a (unique) hostname to be entered/automatically generated on install False. And is there any reasoned argument instead of the simple 'false'? It seems pretty obvious: no OS can require a unique hostname at install time, because it has no way of checking uniqueness. The Unices I've installed (various versions of Solaris and Linux), even if they prompt for a hostname, will accept the default of "localhost.localdomain". In addition, many, many machines (especially those bought preinstalled) are installed from standardized images, and have standardized hostnames. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. In any other way do you like remembering and typing over 128bit addresses?? :) :: is your friend. If you're building an ad hoc, point-to-point network, you can pick convenient addresses. Most OS's require a (unique) hostname to be entered/automatically generated on install False. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about names and addresses
Keith Moore wrote: > From: Keith Moore <[EMAIL PROTECTED]> > HIP only solves part of the problem ... it doesn't provide any > way of mapping between that identity and an address where you > can reach the host. without a mechanism to map the endpoint identifier to an IP address, such identifiers are useless in referrals between application components. Not completely useless; they would prevent the problem of reaching the *wrong* endpoint. This isn't much help if you have only one address for the endpoint you want; but, if you have a global and a local address for it, and you get the wrong HIP from the host that answers when you use the local address, then you know not to use that one. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Stephen Sprunk wrote: I've dealt with many companies interconnecting where both use RFC1918 space -- NAT is the first thing discussed. You forget, these people are connecting for a _business reason_ and there is real money to be lost if they mess up. And how much real money do they lose by having to work around those NATs? -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Tony Hain wrote: Margaret Wasserman wrote: Of course, in the case of site-local addresses, you don't know for sure that you reached the _correct_ peer, unless you know for sure that the node you want to reach is in your site. Since the address block is ambiguous, routing will assure that if you reach a node it is the correct one. That's backwards: Since the address block is ambiguous, routing *cannot* assure that if you reach a node it is the correct one. Nobody can, because we equate addresses with identities. Consider a peer-to-peer conferencing session, with three participants A, B, and C. A and B are at the same site; C is at a separate site; both sites use the same range of site-local addresses. Each has two addresses, AG, BG, CG and AL, BL, CL (Global and Local). A initiates the session by connecting to B and C (assume for the moment that this is not a problem). B and C provide A with their addresses; to complete the mesh, A tells B to connect to C at CG or CL. Now, B isn't going to connect to *both*, so it'll have some heuristic to pick one. Suppose it picks CL (*). But, whoops, B's site has some host D, with DL==CL. So B winds up connecting to the wrong host, and doesn't realize it. (*) Not an unreasonable supposition. If the app is looking at the addresses, it might well notice that CL is on a locally attached subnet, and use that. Or the app might connect to both in parallel (non-blocking connect()), and use the address it reaches first, as a first cut at discovering the most efficient path (that's what I did when I implemented this some time back). Being on the same network, D will probably respond before C. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE: sitelocal addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: site locals do not provide a well known flag because an application has no idea about the site boundary, Or boundaries: consider a private LAN where one part is firewalled from other parts of the same site. The single flag "this address is site-local" cannot mark that boundary. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Keith Moore wrote: On Thu, 27 Mar 2003 15:31:23 -0500 John Stracke <[EMAIL PROTECTED]> wrote: Besides, we have three such prefixes, given RFC-1918 and 6to4: 2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32. the same problems exist for these as for SLs. Right. we should deprecate these also when we revise 6to4. Perhaps; but, given the prevalence of RFC-1918 addresses, it's unlikely that anybody's going to build their 6to4 implementation to block it from using them. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Margaret Wasserman wrote: As you know, I was in favor of setting aside a prefix (FECO::, in fact) for use as private address space (either on disconnected networks, or behind NATs), but the consensus of the folks in the IPv6 WG meeting was to deprecate that prefix altogether. There were several compelling arguments from operators and others that we don't need a special prefix for disconnected sites... Besides, we have three such prefixes, given RFC-1918 and 6to4: 2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: IPv6, interNAT, Wi-Fi (not mobile)
Harald Tveit Alvestrand wrote: Tastes much like a MANET network to me. Well, yes. Internally, that's fine; and a MANET community wireless network is a great idea. It's just that, externally, you don't want that ad hoc network exposing its internal structure, or its routing updates will be horrific. A solution to that would probably be a solution to the general problem of route flap. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: Financial state of the IETF - to be presented Wednesday
Mark Allman wrote: "Self-funded" is problematic, though: how do you tell the difference between someone who really is paying his own way and someone who's going to expense it? And what about a consultant with his own small business; if he owns the business outright, and the business pays the way, is that self-funded or not? Maybe a bit -- but, if you're self funded then you have no affiliation on your badge. So I could pass for self-funded by not telling putting down a company name on my registration? I think other organizations make this kind of distinction work by giving more rights to people who pay more; that would be the opposite of what we want to do here. I was specifically thinking of SIGCOMM's student travel grant program -- in which the above is not the case. But "student" is a well-defined class, with a moderately good means to check. "Self-funded" is neither. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: IPv6, interNAT, Wi-Fi (not mobile)
Fred Baker wrote: Using it as ad hoc, I think you want to not relay route flaps to your providers. Rather, you want to advertise your prefix (however obtained) to them en mass, and handle the routing issues internally. This may mean providing wired connectivity between your various points of attachment to your providers, to mask the internal motion. Or, failing that, some more firmly nailed-up wireless connectivity. If you can get line-of-sight between your attachment points, then two high-gain antennas and two UPSes would be cheaper than most wired connections, and probably almost as reliable. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: IPv6, interNAT, Wi-Fi (not mobile)
S Woodside wrote: On Tuesday, March 25, 2003, at 06:03 PM, John Stracke wrote: proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. I understand that it's difficult, but it's also important. Well, yeah. If you could solve it, the solution would be applicable to all networks, and would substantially improve the stability of the Internet. So obviously lots of people (not me; I'm not a routing expert) have thought about it; the fact that it hasn't been solved yet should discourage you from making plans that assume it will be solved. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: IPv6, interNAT, Wi-Fi (not mobile)
S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. Right. The problem is that what I've seen in the past is that wireless-mesh proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. -- /========\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: slide fonts
Scott W Brim wrote: I don't know anyone who has asked for hardcopy proceedings for years. I remember seeing a set ordered by a coworker about 2 years ago. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |When rats leave a sinking ship, where exactly do they think| |they're going? | \===/
Re: charging for IETF participation
Dave Crocker wrote: Choosing to charge for things like I-D authorship or mailing list posting (or subscription) carries some practical challenges. If we charged for subscription, we'd have to make sure that the archives became available for free eventually; otherwise we're a lot less open to peer review. Even with that, charging for subscription sounds like a nightmare; we'd have people missing important messages because their credit cards expired at just the wrong time. Charging for posting will reduce feedback from outside the WG. Besides, it sounds a lot like solving the spam problem. ;-) -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"We can't duplicate the bug." "Have you tried the Xerox machine?"| \=/
Re: Muttered at the IESG Open Mike...
Harald Tveit Alvestrand wrote: anyone who gets an RFC published gets 10 tokens; anyone who gets a standards-track document published gets 20. Suddenly there's even more pressure to put everybody in the WG on the list of authors. :-) -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |"We can't duplicate the bug." "Have you tried the Xerox machine?"| \=/
Re: Fwd: Re: Financial state of the IETF - to be presented Wednesday
Margaret Wasserman wrote: We could attempt to increase fundraising for ISOC/the IETF. One risk there: If the IETF became too dependent on big donors, its neutrality could be threatened. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: Financial state of the IETF - to be presented Wednesday
Mark Allman wrote: So, we raise the fees to cover our expenses, but continue to offer the possibility of a break by applying for a reduced rate from some "fee grant fund". Processing those applications would mean lots more work for the Secretariat. And then there'd be the time spent on people complaining because they were turned down. (And, there would be several well-known categories of folk who would be helped: academics, students, self-funded, folks from non-profits, whatever) "Self-funded" is problematic, though: how do you tell the difference between someone who really is paying his own way and someone who's going to expense it? And what about a consultant with his own small business; if he owns the business outright, and the business pays the way, is that self-funded or not? I think other organizations make this kind of distinction work by giving more rights to people who pay more; that would be the opposite of what we want to do here. -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |Don't anthropomorphize computers. We don't like it.| \===/
Re: Financial state of the IETF - to be presented Wednesday
John Lazzaro wrote: Instead of trying to fix the current model (meeting fees subsidize a publishing arm), it might make sense to consider having the publishing arm be self-funded. This would be anathema to the IETF; it would impose a much higher barrier to implementers, and make it expensive for third parties to determine whether or not a given implementation is compliant. Both of these would have the effect of lowering the quality of implementations. Of course, it might be the only way; but we should look *hard* for alternatives. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Financial state of the IETF - to be presented Wednesday
Harald Tveit Alvestrand wrote: The BIG number in these discussions is the cost of the access line to the hotel - the discussions on price of this single item for San Francisco apparently ranged all the way from 10 KUSD to 80 KUSD, depending (among other things) on the shortest period of time the local-access company was willing to sell this service for. It might be possible to find people to *partially* sponsor the terminal room, by letting us set up a fixed-wireless link to their nearest facility and route through their line. Less cash outlay for them, plus it might let us sidestep the extra charges hotels usually (?) levy when you bring in a phone line. The problem would be getting a sponsor who's got that much spare bandwidth in line-of-sight from the hotel; it'd probably mean the only choices would usually be telecom providers. And any provider that close to the hotel would be on the short list of people from whom to buy access, so sponsoring us would be equivalent to giving away the line. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Financial state of the IETF - to be presented Wednesday
Harald Tveit Alvestrand wrote: OTOH, perhaps people could live from lunch to dinner without cookies??? Or perhaps they could buy snacks in a local store and bring them into the meeting? That way everybody gets their preferred food, too. It'd be a little less social than everybody standing around breaking cookie together, though. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Financial state of the IETF - to be presented Wednesday
Theodore Ts'o wrote: At one point, I was told that Europeans were paying roughly the same for intra-European travel as they were to travel to North America, That seems odd, given the European rail network. I don't know what it costs a la carte, but I know that, both times I've flown to Europe and gotten a Eurailpass (30 days one time, 15 days another time), the pass cost less than the flight. It costs extra in travel time, of course. -- /=======\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: IAB policy on anti-spam mechanisms?
John Kristoff wrote: Perhaps the notion of a well known port is a concept whose time has passed. At least for connection oriented protocols, doing away with well known ports might have some good properties for some basic authentication/cookie mechanism as well. Well, there's SRV records; but that basically pushes the problem up a layer. If services are identified by well-known service names in the SRV record, then people will start filtering at the DNS level. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |If God had meant us to be in the Army, we would've been born with| |green, baggy skin. | \=/
Re: Network Working Group
Bob Braden wrote: *> Perhaps with a pointer to where the archived discussions of the working *> group might be found? The archive of early NWG discussions is the RFC series itself. The other archives, which no doubt existed, were written on DEC tapes, IBM 360 mainframe files, etc. Not too useful today. I believe he meant for new documents. I'm not sure, of course, since he put his comments at the start of his reply instead of alongside the quoted text he was referring to. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Who died and made you king?" "My father."| \==/
Re: Network Working Group
Donald Eastlake 3rd wrote: I sometimes put the working group name on drafts also. But an RFC is never issued by a working group. It is issued by the I* after IESG review and usually after IETF Last Call. I'm dubious about putting the WG name in the RFC but if that were done, As a practical matter, if one wants to find people to discuss an RFC with, knowing what WG it came from (if any) can save steps. The authors' addresses are included, of course, but those sometimes go stale before the WG closes down. -- /====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Diplomacy: The art of letting someone else have your way| \/
Re: Acronyms Et Al. (was: Last Call: Instructions to Request forComments (RFC) Authors to BCP)
Tomson Eric (Yahoo.fr) wrote: - an acronym is a word composed of initials ; e.g.: ASAP, LASER, NATO, OSI, RADAR, SCUBA, are well-known acronyms. They sound like words, while they are actually groups of initials. - initials are the first letters of words ; e.g.: IETF, CIA, FBI, IBM, RFC, TCP, are well-known initials, too complex to be used as acronyms. I never heard this distinction before today. It seems like a pretty strange hair to split in a written forum like the IETF. It boils down to how hard a series of letters is to pronounce in English; but most of our communication doesn't get pronounced. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Collect call from reality, will you accept the--" *click*| \==/
Re: Just three questions
Tomson Eric (Yahoo.fr) wrote: Just three questions : 1/does the IETF support or contest the "Inclusive Name Space" (the one operated by NewRoot instead of the ICANN)? RFC-2826 answers this. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |A computer without Windows is like a chocolate cake without| |mustard. | \===/
Re: Searching for depressing moments of Internet history.....
Simon Spero wrote: I believe Kapor's law was first stated at the January '92 Usenix (The first use for any new communications technology is sex). Not exactly a new phenomenon--the oldest statues known, going back over 20,000 years, are figures of nude women. Objecting to it is like getting depressed about the fact that we still need to eat. -- /=====\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |Cogito ergo Spud. (I think, therefore I yam.)| \=/
Re: Wireless in future meetings
John C Klensin wrote: Folks, the Secretariat is quite good at this stuff. No argument there. :-) -- /=\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |Rope is rope, and string is string, and never the twine shall| |meet.| \=/
Re: Wireless in future meetings
Pekka Savola wrote: I would imagine that the IETF as _customers of the hotel_ can do pretty much what it wants. Depends on Marriott's contract with Wayport--it probably specifies some degree of exclusivity. But Wayport might be happy to grant an exception when they learn the volume of traffic an IETF meeting puts out. :-) -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"I only wish I had time to get married myself, as I've told| |m'wife many's the time." | \===/
Re: Spring 2003 IETF - Why San Francisco?
Harald Tveit Alvestrand wrote: If we get twice as many people as in Atlanta, crowding may be a problem. But twice as many people is a LARGE increase. Besides which, the last IETF meeting in the Bay Area was in 1996; the local population of companies that will pay to send people has probably dropped off a bit since then. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com | |Centiv|My opinions are my own. | || |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \/
Re: After 1 day... Re: text conferencing at the 55th IETF meetingin Atlanta
Franck Martin wrote: The ultimate trick would be to have a speech to text recognition software... So whoever is talking appears as text in the conference room... This would be the lowest bandwidth capable conference system... Not to mention the most entertaining. :-) Your average speech-to-text engine (I use ViaVoice for programming) needs serious training, and would need heavy customization to be able to recognize the IETF vocabulary. I dictated this line from the impp session: Proposal is to use a randomizer in the initial counter value - it replaces the SPI, and is larger than the SPI field, using smaller IV and counter and got: Proposal list use randomizes minister come to value it places the SPI and is larger than the S P I felt using smaller and counter That's pretty good, but hardly up to the level needed for holding a meeting--and this is with an engine trained to my voice. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |I'm a .sig virus...and, boy, am I tired! | \===/
Re: text conferencing at the 55th IETF meeting in Atlanta
Marshall Rose wrote: Very nice. Can these logs be included in the minutes, or alongside them? that's up to the minute taker. remember that there isn't a moderator in the chatrooms, so it's not really a "record", per se. True; but it could still be a useful log, provided there's a scribe reporting what's going on in the room. It would be possible for the logs to be gathered up and included with the minutes, as a supplement; that wouldn't take extra effort from the minute takers. But maybe we should wait and see whether the logs are actually useful. (Personally, if I were going to the meeting, I'd volunteer to be both minute taker and scribe; then I'd take what I'd scribed to the chat room and turn it into minutes. No point having to find two volunteers.) -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: text conferencing at the 55th IETF meeting in Atlanta
Marshall Rose wrote: Each conference room also has a 'bot which records everything that gets sent: Very nice. Can these logs be included in the minutes, or alongside them? -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Does anyone use message/external-body?
On Fri, 2002-11-15 at 14:17, Eric A. Hall wrote: As to the larger question, I'm opposed to replacing the external links with URLs. There are just as many known problems with rendering long URLs as there are with message/external-body entities (eg, your example folded and became unusable in Mozilla). But you can put URLs into message/external-body (see RFC-2017). This would be easy for receiving MUAs to implement, since most have access to a browser one way or another; and it would be easier for users to work with, since people are accustomed to URLs by this point. Some MUAs already let you drag a link from a browser, or specify an attachment by URL; adding the option to send it as a message/external-body instead of inline would be a very small extra for users to learn. -- /====\ |John Stracke | http://www.centivinc.com |HTML OK | |Principal Engineer|=| |Centiv|"Simply vanished--like an old oak table."| |[EMAIL PROTECTED]|--Lord Percy, _Black Adder II_ | \/
Re: kernelizing the network resolver
V Guruprasad wrote: In short, you continue to have the full socket API with no impediment to its use. This is misleading. You say that your main motivation here is to move the identification role out of IP up to DNS, and moving the resolver into the kernel is a necessary first step for that. But it's not a sufficient first step; to eliminate IP addresses as identifiers, you have to remove the socket API. Since you can't strip the id role from names, it must be stripped from IP, and that's what my thesis is about. ] You can't strip the ID role from IP, either, unless you provide a new form of ID for transport protocols to use. -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: kernelizing the network resolver
V Guruprasad wrote: On Tue 2002.11.05, John Stracke wrote: The problem is that only the app knows what kind of caching behavior it needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching is fine; for a more sophisticated protocol (e.g., any sort of videoconferencing app), it may be necessary to ensure that each connection associated with a given session go to the same address. I see both as largely system calls API issues, permitting simple and elegant solutions, and as not fundamental networking constraints that would legitimately rule against the INFS approach. I disagree. The answers you give seem to say that you assume there are only a few possible variations on an application's needs, which is not the case. As Vahalia (Unix internals book) describes, different network filesystems involve very different caching behaviours, meaning that the VFS name tree cache already caters to a wide variety of desired behaviours. The Linux VFS, for example, provides for per-node ttl, and can be manipulated on a per- process basis by setting mode parameters specifying the cache control before "opening" the nodes. (a) This requires that the kernel be able to support the cache logic that the app needs. The only way to support apps with novel requirements is a minimalist API on which the app can build its own logic. That's the lesson of Unix--and, for that matter, of IP. (b) Per-process is not sufficient, because a given process may need several different styles of caching. For example, consider a conferencing program with an embedded LDAP client. For the second requirement, a simple known approach is to pass the already open (socket) file descriptor as argument when opening the secondary connections, so that the fd serves as an abstract handle for the previously obtained address. That works only if the first connection is still open. In addition, not all applications use connected sockets. If you're using a UDP-based protocol, it may be more efficient to have a single unconnected socket, and specify the recipient address on each packet you send. This is especially true for servers; if you've got lots of requests coming in, and they don't require a lot of user-space CPU, then the cost of creating a new socket for each request could add significantly to the cost of serving the requests. The fixed-length numeric addresses still need to exist, and their nature still needs to be coded into all hosts and routers. Hiding them from the apps will not make it easier to upgrade the installed base. No, but it would avoid inertia from the apps, whose hardcoding for IPv4 sockaddr's does pose some problems for v6 migration and dual support in wireless devices and appliances. And you think you won't encounter inertia trying to get people not to use sockaddrs at all? The sub-problem of preserving TCP connections has been variously addressed in other scenarios, e.g. in Snoeren and Balakrishnan's Mobicom'00 paper. There are TCP protocol extension proposals to allow renumbering of end points within the connection. Securely? And what about all the non-TCP-based protocols? -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: kernelizing the network resolver
V Guruprasad wrote: On Fri 2002.11.01, Keith Moore wrote: so when the address changes out from under the app, or there are multiple hosts bound to a single domain name, the app loses. I don't see why name-address caching within the kernel cannot be as good or as bad as caching in the user space. I believe this would be an important area that the current Linux implementation of INFS allows. The problem is that only the app knows what kind of caching behavior it needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching is fine; for a more sophisticated protocol (e.g., any sort of videoconferencing app), it may be necessary to ensure that each connection associated with a given session go to the same address. Very briefly, the two main reasons are (a) that any fixed-length numeric address space automatically sets a hard limit and resists expansion, as we are finding from the IPv6 migration, The fixed-length numeric addresses still need to exist, and their nature still needs to be coded into all hosts and routers. Hiding them from the apps will not make it easier to upgrade the installed base. and (b) not depending on fixed-length numeric addresses as primary (user & application level) addresses would enable the network to auto-aggregate its addresses and routes. You're talking about permitting automatic renumbering. How does that happen without disrupting established TCP connections? -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: kernelizing the network resolver
V Guruprasad wrote: - eliminates sockaddr_t handling in the user space, allowing application code to become free of IPv4/IPv6 (or for that matter raw Ethernet or ATM) dependencies; Doesn't using a shared library for the resolver give you the same benefit? It's in user space, but it's not in the app. - reduces the number of context switches going from application to resolver and back; Do you have data showing these context switches are a problem? To me, it seems like you're optimizing something that doesn't take up that much time anyway--what apps spend that much CPU time on DNS lookups? - provides robust kernel multitasking for the resolution process, avoiding buggy or unsafe multithreading in application-based resolvers (like in netscape); Again, the same thing can be done with a good shared lib. Most current Unices include gethostbyname_r(), which is thread-safe. Netscape just started too early, when threading support in the OS was still pretty uneven. - reduces the overall code footprint - the filesystem name tree cache is reused, sockaddr_t handling code in applications gone. Again, shared libs also reduce duplicate code (though not data; for that you do need the kernel, or a daemon). -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: mail headers for announce
Dave Crocker wrote: Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. Or perhaps what post offices it went through on the way. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Palladium (TCP/MS)
Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Palladium (TCP/MS)
[EMAIL PROTECTED] wrote: And anyhow, using a router block is a bad idea in this case. There's two cases - either you still have machines using that vendor's software, and you WANT them to reach the servers so they can update, That doesn't necessarily follow. I read a report (*) today that the EULA for XP/SP1 and 2000/SP3 states that, if you use automatic updates, you grant MS, and its designated agents, access to your "software information"--which is vague enough to include any data on your system. That's probably not what they intended, but the possibility is bad enough that financial and medical institutions in the US (and, probably, all companies in Europe) cannot legally use the automatic update systems, because they would be violating privacy laws. So a company might decide that they had to ban autoupdate, and do all updates manually, in which case it would be reasonable for them to block access to the update servers. (*) http://cin.earthweb.com/article/1,3555,10493_1485861,00.html -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
Timur Shemsedinov wrote: Here question, whether is necessary to have two realizations of the RPC using XML? Again, it's not up to the IETF; XML-RPC already exists. And, in fact, it predates SOAP. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
Timur Shemsedinov wrote: >1. How it can work in local networks if IANA is not accessible and >profiles can be received neither from the client nor from the server >of such network? Or they are placed locally, if so why URL refers to >iana.org ? > It's not used as a URL; it's used as a URI. You don't resolve it; you just use it as an identifier. This is a common tactic in XML. -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: RFC 871
Bill Cunningham wrote: >I've noticed they've confused axioms >which are taken to be true as a ground work for something with Euclidean >postulates, which are truths to be self evident. > > (a) You have that backwards. Euclid had axioms, which were taken as self-evident (e.g., "things equal to the same thing are equal to each other") and postulates, which were taken as the basis of geometry (e.g., "all right angles are equal"). (b) Modern mathematicians do not differentiate between axioms and postulates, because nothing is self-evident. "Things equal to the same thing are equal to each other" is not a statement of absolute truth, it's a property of the equality relation you choose to use. -- /=======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: broadcast packets
[EMAIL PROTECTED] wrote: >On Wed, 25 Sep 2002 10:33:52 +0200, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> said: > > >> I'm Marco from Italy and I'm working on a security LAN project. >>I have to analyze all the hosts on my ethernet relying on their >>broadcast packets. >> >> >You might want to ask yourself exactly what you're trying to accomplish by >trying to fingerprint systems based only on broadcast packets? > > Maybe he meant "broadcast" at the physical layer? I.e., he's on a hub, and he's sniffing the traffic. Marco, is that what you intend? -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |Ea est fabula nostra, et non mutabimus eam! --House Falconguard| |and Affiliated Scum| \===/
Re: INTERVIEW comments by Conrad on IPv4
Joe Baptista wrote: >Incidentally >rfc 1918 is irrelevant to it - those are internal border addresses - non >public "Address Allocation for Private Internets". Unless I'm missing >something it's the public address network. > Vladis's point was that using addresses not assigned to you on the public network was like using RFC-1918 addresses on the public network. -- /======\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com | |Centiv|My opinions are my own.| |==| |"Where's your sense of adventure?" "In front of a roaring fire| |with a cup of cocoa." | \==/
Re: Jabber BOF afterthoughts
Richard Shockey wrote: > this is XML > messaging ...why didnt the Jabber community choose OASIS or W3C..which > strikes me as a more logical home for these kind of things and there is a > larger community of XML expertise there. But using XML is not the hard part. Using XML is nearly trivial; it's just an encoding. Protocols are hard, and that's where the IETF has expertise. -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: the way an I-D takes
John Stracke wrote: > Kai Kretschmann wrote: > >> In mid may we published a draft named draft-kretschmann-kai- >> sighttp-00.txt and got at least some responses. > > ...mostly negative, IIRC. OK, this was an unworthy bit of snideness, since nearly all the previous comments came from me. Sorry. -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: Jabber BOF afterthoughts
Randy Bush wrote: >we don't make ethernet standards, ieee does. we don't make sdh >standards, itu does. etc. etc. in this case, i would be careful >not to encroach on w3's toes. > > What would Jabber have to do with the W3C? It's a protocol, not a document format. Furthermore, we already have two efforts in this space; if the W3C were likely to object, they would've by now. -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: the way an I-D takes
Kai Kretschmann wrote: > what further way goes a submitted and published internet draft after a > short period of discussion? urn:ietf:rfc:2026 > In mid may we published a draft named draft-kretschmann-kai- > sighttp-00.txt and got at least some responses. ...mostly negative, IIRC. -- /====\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: (ietf54-noc 1798) why we had wireless problems at IETF
Atsushi Onoe wrote: >We should expect AP vender to update their software to handle >IETF meeting and other such congested wireless terminal environment, >if any... > > I suppose it's possible that there are no other environments as congested as the IETF...but the 802.11x vendors need to hope that there will be. It might be possible to get them to treat the IETF as an opportunity to stress-test their access points. For Atlanta, the host is Nokia, which sells an access point (<http://www.nokia.com/corporate/wlan/point_a032.html>); maybe the organizers could talk to their engineers and get debugging models. Better to do it with the IETF, which is capable of understanding why debugging is hard, than with a flash crowd at Starbucks. :-) -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
Robert A. Rosenberg wrote: > At 22:59 -0700 on 07/03/2002, [EMAIL PROTECTED] wrote about Re: > The MTA then decides what Transforms are > needed (based on the CONNEG info) and grabs out those that are needed > from the M-P/A set. This removes the Real-Time transform overhead by > off-loading it to the Client. It is, of course, based on a model > where the number of different transforms are limited AND can be > enumerated in the absence of info on the capabilities of the > designated recipients. ...and where you're not interested in signing the message. -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: Last Call: SMTP Service Extension for Content Negotiation toProposed Standard
Gerry Sancataldo wrote: > I am involved in the technical support/ training area for fax and > internet fax devices and would just like to add that typically a > message/transaction is directed to one recipient only. > In part, though, that's because fax machines have limited UIs; they may support one-to-many, but they don't usually make it easy. Fax software typically has better UI support for one-to-many, and I believe fax-over-IP would lead to software displacing fax machines. Fax-over-POTS software doesn't help if you don't have POTS at your desk, which many business users don't; fax-over-IP software would open things up more. So fax-over-IP would probably lead to an increase in the prevalence over one-to-many. -- /========\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
