Re: Use of LWSP in ABNF -- consensus call
On Mon, 14 May 2007, Dave Crocker wrote: Could cause problems in other places... The DKIM hiccup was the first one I'd heard about. By contrast, linear-white-space was defined in RFC733, in 1977, with RFC822 retaining that definition. It is defined in those places as essentially the same as LWSP in the current ABNF Draft Standard specification. The LWSP defined in ABNF is more like the one in HTTP than the message format one, in that 4234 allows space-only lines (it allows multiple CRLFs in LWSP) whereas 2822 does not (at most one CRLF in FWS). There is some documentation of the interoperability problems arising from the implied-LWS rule in HTTP here: http://www.and.org/texts/server-http#implicit-lws Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ GERMAN BIGHT HUMBER THAMES: NORTHWEST BACKING SOUTHWEST 4 OR 5, OCCASIONALLY 6 OR 7 AT FIRST. MODERATE, OCCASIONALLY ROUGH IN GERMAN BIGHT. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
Hi, On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..] ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. [..] The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. Not quite. If ICANN decides we won't listen to IETF anymore, or we try to inforce non-useful politics to the RIRs there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to IETF - NRO - RIRs Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution. The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures. So this is all sort of academic. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
In message [EMAIL PROTECTED], Tony Hansen [EMAIL PROTECTED] writes Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. Agreed - well put. I could see a note being added. However, anything more than that is totally inappropriate. I would vote against even adding a note. It seems disproportionate to change a 10 year specification at this late stage on the basis of a single case of a misapplied, but valid, rule in another specification. Regards -- Paul Overell Internet Platform Development Manager, Thus plc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
The US DoC has as much say for ARIN as it does for the RIPE NCC. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs. Ray -Original Message- From: Gert Doering [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 4:40 AM To: Dean Anderson Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? Hi, On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..] ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. [..] The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. Not quite. If ICANN decides we won't listen to IETF anymore, or we try to inforce non-useful politics to the RIRs there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to IETF - NRO - RIRs Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution. The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures. So this is all sort of academic. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
I had followed up to Tony's note privately with Tony/Lisa/Dave yesterday, but perhaps I should have posted it here. No time like the present. I agree that technical changes to a specification as it moves from Draft to Full does not seem helpful. Although we have darned little experience actually DOING this, RFC 2026 says 4.1.3 Internet Standard A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. So, it seems to me that the bar for changing technical aspects of the specification needs to be very high, since this specification has been significantly implemented and successfully operated for a while now. Specifically, a deprecation statement would make sense if LWSP is ALWAYS a bad idea, but we don't seem to be saying that. So I would speak against deprecating. I believe that the IETF has a responsibility to implementers. Anytime we know there is a dragon, we should say there be dragons. So I would speak in favor of adding a warning note that clearly points to a dragon when this specification is used in a new specification. Thanks, Spencer p.s. I have to smile a little that we're talking about ABNF being used in new protocol specifications after 10-30 years, depending on who is counting. I wish ALL of our draft standards, and full standards, were as helpful to the Internet community. From: Paul Overell [EMAIL PROTECTED] In message [EMAIL PROTECTED], Tony Hansen [EMAIL PROTECTED] writes Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. Agreed - well put. I could see a note being added. However, anything more than that is totally inappropriate. I would vote against even adding a note. It seems disproportionate to change a 10 year specification at this late stage on the basis of a single case of a misapplied, but valid, rule in another specification. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: The IESG reviewed http://www.ietf.org/internet-drafts/draft-crocker- rfc4234bis-00.txt for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, as it has caused problems recently in DKIM and could cause problems in other places. Some discussion on this point already: - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html - https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid=66440 (in this tracker comment, Chris Newman recommended to remove LWSP, but for backward-compatibility it's probably better to keep it and recommend against use) I think it would be better to keep LWSP and recommending against its use. Running grep on various RFCs shows that this production is referenced in several RFCs, even in some recent ones. I don't object to Chris' idea to add FWS to the ABNF document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Paul Overell [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tony Hansen [EMAIL PROTECTED] writes Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. Agreed - well put. I could see a note being added. However, anything more than that is totally inappropriate. I would vote against even adding a note. It seems disproportionate to change a 10 year specification at this late stage on the basis of a single case of a misapplied, but valid, rule in another specification. I did some research, and found the following mentions of LWSP: rfc0733 obs-by rfc0822 rfc0822 defs LWSP-char = SPACE / HTAB obs-by rfc2822 rfc0987 refs rfc0822 rfc1138 refs rfc0822 rfc1148 refs rfc0822 rfc1327 refs rfc0822 rfc1486 refs rfc0822 rfc1505 refs rfc0822 rfc1528 refs rfc0822 rfc1848 defs LWSP-char ::= SPACE / HTAB rfc2017 refs rfc0822 rfc2045 refs rfc0822 rfc2046 refs rfc0822 rfc2110 refs rfc0822 rfc2156 refs rfc0822 rfc2184 refs rfc0822 rfc2231 refs rfc0822 rfc2234 defs LWSP = *(WSP / CRLF WSP) obs-by rfc4234 rfc2243 refs rfc0822 rfc2378 defs LWSP-char = SP | TAB rfc2530 refs rfc2234 rfc2885 defs LWSP = *(WSP / COMMENT / EOL) rfc3015 defs LWSP = *(WSP / COMMENT / EOL) rfc3259 defs LWSP = *(WSP / CRLF WSP) rfc3501 refs rfc2234 rfc3525 defs LWSP = *(WSP / COMMENT / EOL) rfc3875 defs LWSP = SP | HT | NL rfc4234 defs LWSP = *(WSP / CRLF WSP) rfc4646 refs rfc2434 Based on this, I recommend outright deprecation. The RFC4234 definition is wildly different from the RFC822 usage (which is substanitally more often referenced): thus any use of it will tend to confuse. It's also a bit dubious, quite specifically allowing lines which appear to be blank, but aren't. :^( The RFC4234 definition, in fact, is referenced by only 3 RFCs: RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 RFC4646 Tags for Identifying Languages The use under RFC2530 is a bit vague (with LWSP wrapping); likewise under RFC3501 (otherwise treat SP as being equivalent to LWSP). The use under RFC4646 has caused known problems. This would seem to justify deprecation, IMHO. YMMV, of course... -- John Leslie [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
The US DoC has as much say for ARIN as it does for the RIPE NCC. The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say' Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC. You seem to be confusing delegation of authority with loss of authority. The DoC has contracted the IANA function to ICANN and doesn't involve itself much, and ultimately plans to get out altogether. However, the IANA operator (ICANN) then has 'much say'. But the DoC 'get out altogether' event hasn't happened yet. So you can't write out the DoC just yet. Don't how you arrived at that conclusion based on a casual observation. Not writing them out, don't know how you got that. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs. The fallacy of this claim was already stated: What is false about those statements? RIRs get their authority and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government. Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs. Ray ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: 2. The ABNF is a candidate for moving from Draft to Full. Will removing a rule (that is already in use?) or otherwise changing the semantics of the specification, at this point, still permit the document to advance? I had the impression that moving to Full was based on some serious beliefs about a specification's being quite stable. Making this kind of change, this late in the game, would seem to run counter to that. Moving to Internet Standard is indeed something we do carefully, and of course that means investigating proposed changes to make sure they're appropriate, and setting a high bar for accepting them. I believe that's what we're doing here, investigating carefully. I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. Removing features that have proved to be a Bad Idea has always been listed as one of the possible changes from Proposed to Draft - Draft to Full happens so rarely that I would be hesitant to claim that there's tradition for such changes there. Despite this, I agree with the people who think that a warning comment, rather than removal of the rule, is the Right Way. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Harald Alvestrand wrote: Removing features that have proved to be a Bad Idea has always been listed as one of the possible changes from Proposed to Draft - Draft to Full happens so rarely that I would be hesitant to claim that there's tradition for such changes there. The question is the proved to be criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: The issue was initially raised by Frank Hi, a short explanation, initially I hoped that 4234 can be promoted to STD as is. I missed the (now listed) errata in the pending errata mbox. Some months later 4234bis-00 was posted, and if 4234 can't be promoted as is, then that's an opportunity to address this (known) LWSP issue. Just removing it is an idea, but for the reasons stated by Dave I felt that just deprecating it is good enough with less undesirable side-effects. After all it's simple to implement LWSP as specified. But unfortunately it's also simple to destroy critical white space in an apparently empty line. Sorry for the confusion, I should have checked the pending errata mbox before the proposal to promote RFC 4234 to STD. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Full agreement with Tony here. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
--On Tuesday, 15 May, 2007 12:03 -0700 Ned Freed [EMAIL PROTECTED] wrote: Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Full agreement with Tony here. +1 ABNF is simply a tool, a grammar, and a set of definitions. I'd almost favor a separate applicability statement that encourages the use of some features and discourages others as appropriate if that is really needed. But a particular element should be removed from the standard only if there is a case to be made that the definition is inadequate or consistent with other parts of the model or grammar. If such inconsistencies actually existed, ABNF should, IMO, be bounced back to Proposed and fixed. Fortunately, that doesn't seem to be the case here, but I would really question what we are doing to ourselves if our grammatical definitions start needing profiles john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Tue, 15 May 2007, Dave Crocker wrote: So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems in HTTP? http://www.and.org/texts/server-http#implicit-lws Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FORTH TYNE DOGGER: WEST 4 OR 5, BECOMING VARIABLE 2, THEN SOUTHERLY 3 OR 4. SLIGHT OR MODERATE. SHOWERS THEN MAINLY FAIR. GOOD OCCASIONALLY MODERATE AT FIRST. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Tony Finch wrote: On Tue, 15 May 2007, Dave Crocker wrote: So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems in HTTP? http://www.and.org/texts/server-http#implicit-lws No. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
On May 15, 2007, at 10:16 AM, John Leslie wrote: I did some research, and found the following mentions of LWSP: rfc0733 obs-by rfc0822 rfc0822 defs LWSP-char = SPACE / HTAB obs-by rfc2822 rfc0987 refs rfc0822 rfc1138 refs rfc0822 rfc1148 refs rfc0822 rfc1327 refs rfc0822 rfc1486 refs rfc0822 rfc1505 refs rfc0822 rfc1528 refs rfc0822 rfc1848 defs LWSP-char ::= SPACE / HTAB rfc2017 refs rfc0822 rfc2045 refs rfc0822 rfc2046 refs rfc0822 rfc2110 refs rfc0822 rfc2156 refs rfc0822 rfc2184 refs rfc0822 rfc2231 refs rfc0822 rfc2234 defs LWSP = *(WSP / CRLF WSP) obs-by rfc4234 rfc2243 refs rfc0822 rfc2378 defs LWSP-char = SP | TAB rfc2530 refs rfc2234 rfc2885 defs LWSP = *(WSP / COMMENT / EOL) rfc3015 defs LWSP = *(WSP / COMMENT / EOL) rfc3259 defs LWSP = *(WSP / CRLF WSP) rfc3501 refs rfc2234 rfc3525 defs LWSP = *(WSP / COMMENT / EOL) rfc3875 defs LWSP = SP | HT | NL rfc4234 defs LWSP = *(WSP / CRLF WSP) rfc4646 refs rfc2434 Based on this, I recommend outright deprecation. The RFC4234 definition is wildly different from the RFC822 usage (which is substanitally more often referenced): thus any use of it will tend to confuse. It's also a bit dubious, quite specifically allowing lines which appear to be blank, but aren't. :^( The RFC4234 definition, in fact, is referenced by only 3 RFCs: RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 RFC4646 Tags for Identifying Languages The use under RFC2530 is a bit vague (with LWSP wrapping); likewise under RFC3501 (otherwise treat SP as being equivalent to LWSP). The use under RFC4646 has caused known problems. This would seem to justify deprecation, IMHO. Agreed. From a standards standpoint, half a dozen definitions for an ABNF mnemonic is absurd. Perhaps something like: The LWSP mnemonic has been deprecated and should not be used in future drafts. Explicit definitions based upon different mnemonics should be used instead. If possible, syntax should guard against possible security concerns related to visual deceptions. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-rohc-sigcomp-sip (Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)) to Proposed Standard
The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) ' draft-ietf-rohc-sigcomp-sip-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-05-29. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=10482rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authentication) to Proposed Standard
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Extension for Digest Authentication ' draft-ietf-radext-rfc4590bis-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-05-29. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that the document includes a Normative Reference to RFC 3579 which is an Informational RFC. This down reference was already approved for RFC 4590. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15568rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
69th IETF - Visa Reminder
69th IETF Meeting Chicago, IL, USA July 22-27, 2007 Host: Motorola For attendees who live outside of the United States, we would like to remind you to check visa requirements for travel to the IETF-69 in Chicago, IL. If your home country does not participate in the Visa Waiver Program: http://www.travel.state.gov/visa/temp/without/without_1990.html then you will possibly need a visa. Visa processing times differ country to country. Please use the following site to get an approximate wait time for you local area: http://travel.state.gov/visa/temp/wait/tempvisitors_wait.php. To learn more about the Visa program or how to request a letter of invitation in order to apply for a visa for travel to the United States, please visit: http://www.ietf.org/meetings/69-invite_letter.html. Only 68 days until the Chicago IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/69-IETF.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
