Re: Death of the Internet - details at 11
On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote: - increased overhead compared to TCP Ok lets see. SCTP takes on average 4 more bytes per data packet then TCP. However, if the TCP implementation enables timestamps then that is not true and TCP takes more overhead by about 4 bytes... Hm... timestamp option takes 12 bytes, what gives? Unless you are discussing another type of overhead... Apart from the extra bytes (which isn't the main issue) there are the CRC32 checksum, which is considerably more expensive to compute than the TCP/UDP/IP checksum and the fact that SCTP has much more complexity. I would be surprised if the fast path for SCTP wouldn't turn out to be more expensive than that of TCP, especially without disabling all the features that make SCTP more interesting than TCP in the first place. And of course those heartbeats I love to hate. (Which don't provide any benefits when there are only two paths anyway.) - requires significant changes from applications Ok let see.. for Mozilla we converted two lines of code Ok, we can discuss whether the changes are significant but the fact that changes are required at all is the main problem. sd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); became -- sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); and setsockopt(sd, IPPROTO_TCP, TCP_NODELAY, on_off, sizeof(on_off)); became --- setsockopt(sd, IPPROTO_SCTP, SCTP_NODELAY, on_off, sizeof(on_off)); So is this enough to gain all multihoming benefits? Even if all other magic is hidden inside the protocol, the application must at least try all possible destination addresses. (But this is true for several other multi6 proposals as well.) Now to take advantage of the stream feature you would need to do more.. but for pure multi-homing one or two lines of change does not seem that big of deal to me ... Doing WWW-style HTTP (lots of concurrent sessions) with SCTP would be nonsense, this is where the feature where multiple streams are multiplexed over a single session would be extremely useful. - no backward compatibility of any kind I am not sure what you mean by backward compatable? You definetly can't have TCP and SCTP talk.. they are after all different protocols... But if an application needs the redundancy move to it.. its there today with about 2 lines of coding change... But then you'll have to run services on both TCP and SCTP pretty much forever. Not a good thing. - source address selection problem isn't addressed fully, if at all I don't think I understand this issue either.. Host has addresses a and b from ISPs A and B. Host sends a packet to address x which is routed over ISP A. However, the host selects source address b which is filtered by A, so no connectivity. For extra credit: solve same when this happens in the middle of a session, and in cases where connectivity consists of two one way paths. (a - x and y - b work, but not x - a or b - y) We have fully addressed source address selection in the KAME implementation. In what way?
Re: Death of the Internet - details at 11
Iljitsch van Beijnum wrote: On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote: - increased overhead compared to TCP Ok lets see. SCTP takes on average 4 more bytes per data packet then TCP. However, if the TCP implementation enables timestamps then that is not true and TCP takes more overhead by about 4 bytes... Hm... timestamp option takes 12 bytes, what gives? Ahh.. I never did the direct comparison at the RFCs... just what I saw in ethereal.. My hosts are BSD based and always send MSS of 1448 bytes. SCTP uses 1452. Looking at the RFC's SCTP is 8 bytes more... Don't think 8 bytes is really a killer.. especially when 4 of those bytes can be used for the application (PPId) And especially since: 1) SCTP is not as subject to the wrap issue so Timestamps are not needed 2) SCTP is not as subject to data and control injection by blind attackers and these come for free as well.. Unless you are discussing another type of overhead... Apart from the extra bytes (which isn't the main issue) there are the CRC32 checksum, which is considerably more expensive to compute than the TCP/UDP/IP checksum and the fact that SCTP has much more complexity. I would be surprised if the fast path for SCTP wouldn't turn out to be more expensive than that of TCP, especially without disabling all the features that make SCTP more interesting than TCP in the first place. And of course those heartbeats I love to hate. (Which don't provide any benefits when there are only two paths anyway.) As to CRC32c .. yes it is more expensive.. but it affords a lot more protection then the TCP checksum. And just like the TCP checksum there are already chipsets out there that do this in hardware... I know intel has such a chipset and I am sure you will see it evolve to other hardware makers as well. As to the other features... if the application is going to have to perform them then you have not removed the cost.. you have just pushed it to a higher layer... - requires significant changes from applications Ok let see.. for Mozilla we converted two lines of code Ok, we can discuss whether the changes are significant but the fact that changes are required at all is the main problem. You don't get new features without change of some sort... sd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); became -- sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); and setsockopt(sd, IPPROTO_TCP, TCP_NODELAY, on_off, sizeof(on_off)); became --- setsockopt(sd, IPPROTO_SCTP, SCTP_NODELAY, on_off, sizeof(on_off)); So is this enough to gain all multihoming benefits? Even if all other magic is hidden inside the protocol, the application must at least try all possible destination addresses. (But this is true for several other multi6 proposals as well.) Yes you get a retransmissions to alternate addresses with this small change. And you don't have to try all the addresses.. just an alternate until you find one that works... Now to take advantage of the stream feature you would need to do more.. but for pure multi-homing one or two lines of change does not seem that big of deal to me ... Doing WWW-style HTTP (lots of concurrent sessions) with SCTP would be nonsense, this is where the feature where multiple streams are multiplexed over a single session would be extremely useful. Yes.. if you wanted to do HTTP over SCTP and use features such as streams you WOULD WANT to extend HTML so that you could have the client get pages on particular streams... Then you could have parrallel transfers over one association and not have to require multiple TCP connections... this is optimal... Jana was doing some investagtion into this at the University of Deleware's Protocol Engineering Lab.. don't know if he will be writting a paper on it.. I imagine so... - no backward compatibility of any kind I am not sure what you mean by backward compatable? You definetly can't have TCP and SCTP talk.. they are after all different protocols... But if an application needs the redundancy move to it.. its there today with about 2 lines of coding change... But then you'll have to run services on both TCP and SCTP pretty much forever. Not a good thing. Just like we are stuck with IPv4 forever as well... Its pretty much a given.. once a new technology comes along it is a slow gradual transition not a mass move. IPv6 as been out since 1993 and we are not only 11 years into the migration.. it will all happen eventually.. but I see many years left for IPv4... and only a slow migration to V6... The same, I think, can be said for SCTP.. and it is very early in this process if you use IPv6 as a gage :-D - source address selection problem isn't addressed fully, if at all I don't think I understand this issue either.. Host has addresses a and b from ISPs A and B. Host sends a packet to address x which is routed over ISP A. However, the host selects source address b which is filtered by A, so no
Re: Wiki RFC
On Wed, Jan 28, 2004 at 05:25:15PM -0800, Harald Tveit Alvestrand wrote: --On 28. januar 2004 12:49 +1200 Franck Martin [EMAIL PROTECTED] wrote: I was just wondering if there has been any work to standardise the Wiki syntax/system into an RFC? AFAIK, no. Do you know of any effort to make stable documentation for the WIKI syntax functionality, or is it just use the Source, Luke? And beware those peddling The wiki syntax. Most engines invent their own. I know the one I've written leans far more to the natural-language side of things at the moment.
Re: Death of the Internet - details at 11
--On Thursday, 29 January, 2004 14:34 +0900 Dave Crocker [EMAIL PROTECTED] wrote: ... JCK Yes. And it may speak to the IETF's sense of priorities that JCK the efforts to which you refer are predominantly going into the JCK much more complex and long-term problem, rather than the one JCK that is presumably easier to solve and higher leverage. I think a simple version of what you want is already available and has been for many years, namely multiple A records in the DNS. (OK. Let's see you respond to _that_ and claim that the response only has picks at nits... Hah!) Of course, multiple A records works, is out there, and have worked for years. But they worked better before we introduced routers (i.e., when the hosts with multiple A records really had interfaces on different networks). Today, it effectively implies having multiple addresses on an interface and multiple local address prefixes running around on the same physical LAN segment. IPv4 was not designed to work well in that environment and, with at least some implementations that are arguably still conforming, it has some unfortunate side effects, such as not really knowing which addresses are local to you and which aren't, at least without setting up local routing tables that are well beyond the capabilities of the typical user. The claim has been made that IPv6 _is_ designed to work in that environment, for whatever that claim may be worth. Perhaps more important, as Noel points out, it doesn't scale very well, at least in terms of the routing fabric. And, as I tried to point out, address preservation policies have had trickle-down effects that make it impractical for small enterprises. Nits? Probably not. best, john
Re: Death of the Internet - details at 11
At 07:43 AM 1/29/2004, Randall R. Stewart (home) wrote: Iljitsch van Beijnum wrote: On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote: - increased overhead compared to TCP Ok lets see. SCTP takes on average 4 more bytes per data packet then TCP. However, if the TCP implementation enables timestamps then that is not true and TCP takes more overhead by about 4 bytes... Hm... timestamp option takes 12 bytes, what gives? Ahh.. I never did the direct comparison at the RFCs... just what I saw in ethereal.. My hosts are BSD based and always send MSS of 1448 bytes. SCTP uses 1452. Looking at the RFC's SCTP is 8 bytes more... Don't think 8 bytes is really a killer.. especially when 4 of those bytes can be used for the application (PPId) And especially since: 1) SCTP is not as subject to the wrap issue so Timestamps are not needed 2) SCTP is not as subject to data and control injection by blind attackers and these come for free as well.. Unless you are discussing another type of overhead... Apart from the extra bytes (which isn't the main issue) there are the CRC32 checksum, which is considerably more expensive to compute than the TCP/UDP/IP checksum and the fact that SCTP has much more complexity. I would be surprised if the fast path for SCTP wouldn't turn out to be more expensive than that of TCP, especially without disabling all the features that make SCTP more interesting than TCP in the first place. And of course those heartbeats I love to hate. (Which don't provide any benefits when there are only two paths anyway.) As to CRC32c .. yes it is more expensive.. but it affords a lot more protection then the TCP checksum. And just like the TCP checksum there are already chipsets out there that do this in hardware... I know intel has such a chipset and I am sure you will see it evolve to other hardware makers as well. As to the other features... if the application is going to have to perform them then you have not removed the cost.. you have just pushed it to a higher layer... - requires significant changes from applications Ok let see.. for Mozilla we converted two lines of code Ok, we can discuss whether the changes are significant but the fact that changes are required at all is the main problem. You don't get new features without change of some sort... sd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); became -- sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); and setsockopt(sd, IPPROTO_TCP, TCP_NODELAY, on_off, sizeof(on_off)); became --- setsockopt(sd, IPPROTO_SCTP, SCTP_NODELAY, on_off, sizeof(on_off)); So is this enough to gain all multihoming benefits? Even if all other magic is hidden inside the protocol, the application must at least try all possible destination addresses. (But this is true for several other multi6 proposals as well.) Yes you get a retransmissions to alternate addresses with this small change. And you don't have to try all the addresses.. just an alternate until you find one that works... I really don't see how this fits with routing policy. You appear to make the assumption that a multi-homed site wants to use the multiple paths as equals. Now to take advantage of the stream feature you would need to do more.. but for pure multi-homing one or two lines of change does not seem that big of deal to me ... Doing WWW-style HTTP (lots of concurrent sessions) with SCTP would be nonsense, this is where the feature where multiple streams are multiplexed over a single session would be extremely useful. Yes.. if you wanted to do HTTP over SCTP and use features such as streams you WOULD WANT to extend HTML so that you could have the client get pages on particular streams... Then you could have parrallel transfers over one association and not have to require multiple TCP connections... this is optimal... Jana was doing some investagtion into this at the University of Deleware's Protocol Engineering Lab.. don't know if he will be writting a paper on it.. I imagine so... - no backward compatibility of any kind I am not sure what you mean by backward compatable? You definetly can't have TCP and SCTP talk.. they are after all different protocols... But if an application needs the redundancy move to it.. its there today with about 2 lines of coding change... But then you'll have to run services on both TCP and SCTP pretty much forever. Not a good thing. Just like we are stuck with IPv4 forever as well... Its pretty much a given.. once a new technology comes along it is a slow gradual transition not a mass move. IPv6 as been out since 1993 and we are not only 11 years into the migration.. it will all happen eventually.. but I see many years left for IPv4... and only a slow migration to V6... The same, I think, can be said for SCTP.. and it is very early in this process if you use IPv6 as a gage :-D - source address selection problem isn't addressed fully, if at all I don't think I understand this
RE: visa requirements (US citizens)
How about this for a twist: if you ask for an invitation (required for a visa), you are told you really, really don't need it. When I requested a visa from TTA, this is the response I got. Has anyone succeeded in getting a letter? -Original Message- From: KeeMoon Roh [mailto:[EMAIL PROTECTED] Sent: Monday, January 26, 2004 1:32 AM To: Eric Burger Subject: RE: [Fwd: Korean Visa invitation letter request for C-2 visa] Dear. Mr. Burger This mail is from 59th Local IETF Secretariats in Korea. Currently we are issuing invitation letters. There is one thing we like to tell you about Korean Entry Visa. USA Nationals who want to visit Korea just for a short-term tour or transit are permitted to enter Korea with no visa according to the principles of reciprocity or priority of national interests with a tourist/transit visa status(B-2, 30days). Event though, it is written that No-Visa Entry is for a short-term tour or transit, participating in short term conventions or meetings(less than 30 days) is allowed as well. I checked this out several times with Korean Embassy. Please refer to http://www.mofat.go.kr/en/visa/e_visa.mof USA citizens, who hold US passport, do not need VISA to attend the 59th IETF Meeting in Seoul Korea, Invitation letter is only for VISA issuing. If you need for some other reason, I can issue you an invitation letter without notarial certificate (not for submitting to Korean embassy). If you still need an invitation letter. please reply to this mail ([EMAIL PROTECTED]). best regards, -- Kee-Moon Roh ??? ??? TTA (Telecommunications Technology Association) * Mobile : +82-11-1735-1161 * TEL : +82-31-724-0075 * FAX : +82-31-724-0059 * E-mail : [EMAIL PROTECTED] ( TTA Secretariat ) * E-mail : [EMAIL PROTECTED] ( 59th IETF Local Secretariat ) -Original Message- From: Paul Hoffman / IMC [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 4:07 PM To: Steve Bellovin; [EMAIL PROTECTED] Subject: Re: visa requirements (US citizens) At 2:31 PM -0500 1/27/04, Steve Bellovin wrote: I was advised by our corporate travel consultants that I should get a visa. Given the current international climate -- there was an article in last Thursday's Wall Street Journal about how other countries are retaliating for the current U.S. fingerprinting and visa application requirements -- this may be a prudent course of action. The Korean embassy page that is linked to from the IETF meetings page (http://www.koreaembassy.org/visiting/eng_visas.cfm) makes it pretty darn clear that US folks should get a visa. They do have a link from that page saying how wonderful US-Korea relations are, of course. Showing up in the airport without a visa and saying but someone at one of your consulates told me I didn't need one may go over as well in other countries as it does in the US... --Paul Hoffman, Director --Internet Mail Consortium
Re: Death of the Internet - details at 11
From: John C Klensin [EMAIL PROTECTED] Of course, multiple A records works, is out there, and have worked for years. But they worked better before we introduced routers (i.e., when the hosts with multiple A records really had interfaces on different networks). Today, it effectively implies having multiple addresses on an interface and multiple local address prefixes running around on the same physical LAN segment. ... Perhaps more important, as Noel points out, it doesn't scale very well, at least in terms of the routing fabric. Sorry? What I said doesn't work for the routing, in terms of scaling to many small sites, is for a multi-homed site to have a single address prefix, which is then globally advertised. (That's the most common tack for multi-homing support in IPv4 to date, which is what you were talking about.) Having multiple addresses for a host (which has only a single physical interface, but which is in a site which is multi-homed) is in fact the only approach whose effects on the routing does scale (within anything like the current routing architecture, i.e. packets which include only source and destination addresses, as opposed to a source route). as I tried to point out, address preservation policies have had trickle-down effects that make it impractical for small enterprises. It is an interesting point (as Daniel Senie also just pointed out) that multiple addresses - faster consumption of the address space. However, since to avoid a size explosion in the routing tables, those multiple addresses do have to be connectivity-dependent (political translation - provider-dependent), I don't see how address preservation policies have made this approach impractical for small enterprises. My understanding of current allocation policies is that ISP's can get enough addresses to cover their customers. If company X is a customer of both ISP P and ISP Q, I would assume that both P and Q don't have a problem getting enough space to cover their customers - including X. (Or were you speaking of the one address block, globally advertized?) Noel
Re: visa requirements (US citizens)
A U.S. citizen does NOT need a visa to visit Korea for a meeting by a non-profit group such as the Internet Engineering Task Force. I just confirmed this with the head of the visa section in the Korean Consulate in Washington DC. Gene, Could you please post the contact information for the head of the visa section of the Korean Consulate? My call to the to the same consolate where I navigated the menus to the visa department resulted in me talking to a person who was ... well, I suppose the kindest thing to say was that he was less than completely confident in his answer. It makes me nervous when two different people talk to the same organization and get two completely different answers. --Ken
Re: visa requirements (US citizens)
How about this for a twist: if you ask for an invitation (required for a visa), you are told you really, really don't need it. When I requested a visa from TTA, this is the response I got. Has anyone succeeded in getting a letter? When I downloaded the visa application form (and checked the Korean Embassy web page), it did not indicate that an invitation letter was required from anyone in Korea. What it did indicate was required (and you can check the web page yourself at http://www.koreaembassy.org/visiting/eng_visas.cfm), is the following (assuming you're a US citizen and you get a business visa): - Visa application form - One passport-sized photo - US Passport - Original copy of company letter on company letterhead _signed by your employer_ (emphasis mine), stating the purpose, name and duration - $ 45.00 USD application fee. - And a prepaid postage return envelope (if applying by mail) While the question of whether or not a visa is required has not in my mind been completely answered, it appears definite to me that you don't need an invitation letter from TTA to get one. --Ken
Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]
I'd like to come back to this point, and try a slightly different direction: Fred Baker wrote: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. I think I would state it in these words: The Internet Engineering Task Force provides a forum for the discussion and development of white papers and specifications for the engineering issues of the Internet. This seems like a reasonable characterization of the output of the IETF. However, it doesn't seem to capture some of the scoping/delimiting that the original text did -- does the IETF discuss any and all such issues? Is it trying to achieve anything in particular by documenting things? (How) can we detect that there are issues we should be discussing and can't? (How) would you add to your text to provide some boundaries/ guiding lines? Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] ---
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: Do we or don't we need a visa for the Korean IETF?
On Jan 29, 2004, at 9:47 AM, John Stracke wrote: 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. I believe the risk is in how one characterizes what an IETF meeting is and why one is attending. I would prefer that we had all had the same instructions on what to say, vetted by the embassy. --aaron
Re: visa requirements (US citizens)
I am an Indian national (which means I need a visa). I know for a fact that I need a produce an invitation letter to get a visa. Please note that I did qualify my note by saying US citizens. Of course entry requirements differ between countries. My point was that US citizens do not need an invitation letter to obtain a visa (from my reading of the visa application form and the on-line documentation). --Ken
Re: visa requirements (US citizens)
I am an Indian national (which means I need a visa). I know for a fact that I need a produce an invitation letter to get a visa. Vijay Ken Hornstein wrote: How about this for a twist: if you ask for an invitation (required for a visa), you are told you really, really don't need it. When I requested a visa from TTA, this is the response I got. Has anyone succeeded in getting a letter? When I downloaded the visa application form (and checked the Korean Embassy web page), it did not indicate that an invitation letter was required from anyone in Korea. What it did indicate was required (and you can check the web page yourself at http://www.koreaembassy.org/visiting/eng_visas.cfm), is the following (assuming you're a US citizen and you get a business visa): - Visa application form - One passport-sized photo - US Passport - Original copy of company letter on company letterhead _signed by your employer_ (emphasis mine), stating the purpose, name and duration - $ 45.00 USD application fee. - And a prepaid postage return envelope (if applying by mail) While the question of whether or not a visa is required has not in my mind been completely answered, it appears definite to me that you don't need an invitation letter from TTA to get one. --Ken
Re: Do we or don't we need a visa for the Korean IETF?
--On Thursday, 29 January, 2004 12:47 -0500 John Stracke [EMAIL PROTECTED] wrote: 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, As I understand it, different embassies and consulates are giving different advice, or advice that is as ambiguous as what is on the web pages (which, for example, do not mention the non-profit categories that have been discussed on this list), with further ambiguities as to what the IETF is. I have now had one consular official tell me that they _will not_ issue a visa if one appears to be unnecessary, even if one shows up with the form, the picture, and the $45 (in my experience, a fairly high fee as visas go). So even the to be safe, get a visa advice that has appeared on the list may not be useful. My own experience is that the Korean immigration folks have been pretty relaxed when one says one is arriving for a professional meeting and a short (under a week or two) stay -- I've never been asked about a visa and I've never been questioned in any detail about, e.g., whether business might be discussed at such a meeting. But, as others have pointed out, there may be some risk of addition scrutiny in reaction to increase border nonsense by the US. To make things even more exciting, those business category visas apparently require a notarized letter of invitation -- apparently hard copy, wet signatures, raised seal -- which can't usefully be posted on the web. So I have to agree with Aaron's analysis. This has reached the point of being insane. Can the secretariat --or whomever is responsible for agreeing to this meeting-- get a definitive statement from an authoritative entity, mentioning the IETF meeting by name, and get it up on the web site in image form, so that we can all print it out and bring it with us (either to the embassy/ consulate if a visa is needed or to show to the immigration official if not). I think, given this level of confusion, that statement needs to be from the Korean Foreign Ministry or equivalent, not whomever answers the phone at a random time in some embassy or consulate. And, if that is not possible, is it time that we hear about the contingency plan for holding this meeting somewhere else? thanks, john
Re: Death of the Internet - details at 11
Noel, (1) Sorry to have misconstrued your comments. (2) Yes, I was trying to refer to situations in which each of the hosts on a multihomed LAN has exactly one address, largely because of bad experiences with client machines running widely-used junk software trying to handle multiple addresses (in IPv4) on the same interface. I know of only two ways to accomplish that exactly one address on local host criterion: (i) use of NATs (even if only on a one-one basis) to make different external addresses appear as a single set of addresses on the LAN and (ii) use of globally-routed, provider-independent, addresses for the LAN. I am now going to drop out of this discussion since I don't seem to be in sufficiently good shape this week to make comments sufficiently precise that I don't just create more confusion. john --On Thursday, 29 January, 2004 11:29 -0500 Noel Chiappa [EMAIL PROTECTED] wrote: From: John C Klensin [EMAIL PROTECTED] Of course, multiple A records works, is out there, and have worked for years. But they worked better before we introduced routers (i.e., when the hosts with multiple A records really had interfaces on different networks). Today, it effectively implies having multiple addresses on an interface and multiple local address prefixes running around on the same physical LAN segment. ... Perhaps more important, as Noel points out, it doesn't scale very well, at least in terms of the routing fabric. Sorry? What I said doesn't work for the routing, in terms of scaling to many small sites, is for a multi-homed site to have a single address prefix, which is then globally advertised. (That's the most common tack for multi-homing support in IPv4 to date, which is what you were talking about.) Having multiple addresses for a host (which has only a single physical interface, but which is in a site which is multi-homed) is in fact the only approach whose effects on the routing does scale (within anything like the current routing architecture, i.e. packets which include only source and destination addresses, as opposed to a source route). as I tried to point out, address preservation policies have had trickle-down effects that make it impractical for small enterprises. It is an interesting point (as Daniel Senie also just pointed out) that multiple addresses - faster consumption of the address space. However, since to avoid a size explosion in the routing tables, those multiple addresses do have to be connectivity-dependent (political translation - provider-dependent), I don't see how address preservation policies have made this approach impractical for small enterprises. My understanding of current allocation policies is that ISP's can get enough addresses to cover their customers. If company X is a customer of both ISP P and ISP Q, I would assume that both P and Q don't have a problem getting enough space to cover their customers - including X. (Or were you speaking of the one address block, globally advertized?) Noel
Visa for Korea (same as Vienna)
My suggestion: do what you did for Vienna. Vienna has the same rules: U.S. citizens in possession of a valid U.S.-passport do not need a visa if traveling to Austria as a tourist for a period not to exceed 90 days (visa waiver program). -Kevin
Re: Wiki RFC
hi, AFAIK, no. Do you know of any effort to make stable documentation for the WIKI syntax functionality, or is it just use the Source, Luke? FYI, there are some efforts, http://www.usemod.com/cgi-bin/mb.pl?WikiMarkupStandard and Japanese Wiki syntax standardization, http://lab.lolipop.jp/fswiki/wiki.cgi/wikistandard (Japanese only) -- /arifumi
Re: Visa for Korea
An attempt to attenuate the visa discussion. The Korean Consulate in Washington DC is preparing an official letter intended to clearly state that U.S. citizens do not need a visa to attend the IETF meeting in Seoul. I will forward a graphic of the letter to the IETF Directorate, who has agreed to post on the web. Suggest giving the visa for U.S. citizens issue a rest for four days, time to get the official letter. Note. I can think of no reason to have a letter of invitation unless you need a visa. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia
Re: SUMMARY: Processing of expired Internet-Drafts
On 1/28/2004 8:15 PM, Harald Tveit Alvestrand wrote: Conclusions, all mine: - Documenting current procedures is good. - We won't expire tombstones. They're not a big enough problem yet. - We'll think about naming tombstones something else than the exact draft name (for instance draft-whatever-version-nn-expired.txt???) - We'll note the issue of referencing names without the version number as input for thinking about overhauling the whole I-D system. But that won't happen very quickly - it mostly works. Seems to make sense? How about using the draft name without a version number as placeholder? That placeholder file can either reference the current version, or it can contain the tombstone text. For example, draft-whatever.txt can either contain a pointer to draft-whatever-nn.txt or can contain text that the last version of that I-D was -nn but has since expired. That eliminates naming collisions, allows for mirroring based on the filedate alone, and provides a running reference to the latest version which can either be fetched directly (if active) or can be retrieved from an archival system (if expired). Other useful information could also be provided in the placeholder, such as referencing the I-D's current progress through the channels, referencing any RFC which may have been published, and so forth. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: visa requirements (US citizens)
One more thing: They won't take a check. Cash and money order are the only things you can send 'em. -- nathaniel On Thursday, January 29, 2004, at 11:48 AM, Ken Hornstein wrote: How about this for a twist: if you ask for an invitation (required for a visa), you are told you really, really don't need it. When I requested a visa from TTA, this is the response I got. Has anyone succeeded in getting a letter? When I downloaded the visa application form (and checked the Korean Embassy web page), it did not indicate that an invitation letter was required from anyone in Korea. What it did indicate was required (and you can check the web page yourself at http://www.koreaembassy.org/visiting/eng_visas.cfm), is the following (assuming you're a US citizen and you get a business visa): - Visa application form - One passport-sized photo - US Passport - Original copy of company letter on company letterhead _signed by your employer_ (emphasis mine), stating the purpose, name and duration - $ 45.00 USD application fee. - And a prepaid postage return envelope (if applying by mail) While the question of whether or not a visa is required has not in my mind been completely answered, it appears definite to me that you don't need an invitation letter from TTA to get one. --Ken
Very summarized version of the mission statement discussion
Hitting some very high points - Talking is important. It's what the IETF does. - Standards are one, but not the only, output of that talking. - Publishing good ideas is important. It's what the RFC Editor does. - Mission statements are dangerous. Discussing them makes you have to admit that you disagree. Hiding the disagreement requires making the mission statements say nothing. - Anything is possible to misunderstand. Especially if it's short. We'll see where we can get from there. Harald pgp0.pgp Description: PGP signature
Re: The IETF Mission
At 12:46 PM 1/29/2004, Leslie Daigle wrote: I'd like to come back to this point, and try a slightly different direction: Fred Baker wrote: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. I think I would state it in these words: The Internet Engineering Task Force provides a forum for the discussion and development of white papers and specifications for the engineering issues of the Internet. This seems like a reasonable characterization of the output of the IETF. However, it doesn't seem to capture some of the scoping/delimiting that the original text did - does the IETF discuss any and all such issues? Is it trying to achieve anything in particular by documenting things? (How) can we detect that there are issues we should be discussing and can't? (How) would you add to your text to provide some boundaries/guiding lines? Thinking out loud here, plenty of room for all to chime in. The key differences, if there are any, between IETF and NANOG and her sisters, and between IETF and IRTF, are: Operationally, IETF discussions address advice to operators (service provider and enterprise, the latter being a group that our operational friends sometimes seem to forget) from the individuals who participated in the discussion, as opposed to discussions among operators. The latter are perfectly welcome and do happen (ptomaine, v6ops), but I would characterize them as often more uniquely the domain of NANOG and her sisters. From a research/innovation perspective, I would characterize the IETF as creating solutions that we in some sense know how to build, as opposed to playing with and learning about possible solutions that we are unsure how to properly build. When we built OSPF, to name one example, it was not from whole cloth; the algorithms were already well defined - we were simply figuring out how to use them. You can say quite accurately that we make our share of mistakes even in what we supposedly know how to do, but at least we can recognize when we do so. In research, 90% of ideas are truly bad ideas, and the other 10% are testing grounds for bits and pieces that will some day contribute to the solution. That is *normal*; research is *supposed* to be risky, to be out of the box. When the researchers have done their job and the engineers come to build a solution for the Internet, the engineers rarely if ever simply adopt research proposals. But they are guided by the wisdom learned in that community, and if they lack that compass, they quickly are lost. I am reminded of an academic researcher who once complained to me that you write too many RFCs. You write the RFC, and we start our research on that RFC. We get part way into it, and you publish a new RFC. I replied to him that the idea is that he is supposed to do the research *before* I write the RFC, so that when I write the RFC I write it once and it is right. If he think he is doing the research afterwards, then in reality I am doing the research and the engineering together, in my customer's networks, and he is doing Quality Assurance. We need the researchers, desperately, but not to do the engineering. We need them to tell us how, to be the pathfinders. We need the operational folks equally desperately. If nothing else, they are the canaries in the mine shaft, and they often can tell us what the mother lode looks like when we see it in the rough. And yes, we need the engineers that are paid by the vendors. Their marketing people are IMHO unwelcome, because they set one person against another for their company's gain, and a house divided against itself cannot stand. But if you think for a minute that the operators and the researchers can do this Internet thing without the products the vendors build, and the engineers that build them, you are sadly mistaken. I am reminded of comments that I have heard in various parts of each of those organizations. Dave Clark, speaking to the Internet II Joint Techs last Tuesday, said that the IETF had forsaken innovation, and had been overtaken by the [evil] vendors. I submit that we - the academics, students, and researchers, the edge network operators that deliver applications running in a network, the transit network operators that deliver bandwidth to interconnect edges, and the vendors, whose products inhabit all of those networks - may not all meet together at the same time or with the same purpose, and we certainly all see things from different perspectives and in different ways. To that extent, perhaps he has a point. But we each play a part in the play. Our strength and our value is not, however, that those of our particular stripe are somehow better than others, or more needed, or have a better level of understanding - that rock breaks scissors, that scissors cut paper, or that paper covers the rock. Our strength, rather, is that we bring our various perspectives together, as a builder
