Re: NOMCOM - Time-Critical - Final Call for Nominations
Hi, On 17 Oct 2013, at 15:09, NomCom Chair 2013 wrote: > A critically low number of people have accepted nominations for some of the > IESG open positions. There is only one nominee per slot in APP, OPS and TSV, > only two in INT and RAI. Many folks have declined nominations. > > While the Nomcom appreciates that support for two years of intense service > is hard to assure, and while we are aware that there is much support for the > incumbents who are standing, the IETF should continually be considering > which new talent is available for our leadership, and the Nomcom process > needs for there to be some review and deliberation. I believe the "intense service" you mention is a significant deterrent for many. I'm sure it's been suggested before, but is there mileage in rethinking the AD roles, and either the number of ADs per area, or whether introducing Assistant ADs or similar might allow people who can contribute less time to do so, while easing the burden on the main ADs? Just a thought anyway. Personally, I'd assume that some people would be more willing to help if deemed to have the skills required, but the time constraints are, as many ADs will confirm if you chat with them, the blocking factor. Tim
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
On 3 Oct 2013, at 18:07, manning bill wrote: > - The following addresses had permanent fatal errors - > > (reason: 550 5.1.1 : Recipient address rejected: > User unknown in virtual alias table) I think the active list is still mdns...@ietf.org? See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html And the 'header' information below should now probably read something like this: --- snip --- Scalable DNS Service Discovery (dnssd) Current Status: Proposed WG Chairs: Ralph Droms Tim Chown Assigned Area Director: Ted Lemon Mailing list Address: dn...@ietf.org To Subscribe: dnssd-requ...@ietf.org Archive: http://www.ietf.org/mail-archive/web/dnssd Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext --- snip --- Tim > > > > On 3October2013Thursday, at 8:42, The IESG wrote: > >> A new IETF working group has been proposed in the Internet Area. The IESG >> has not made any determination yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please send >> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10. >> >> Extensions for Scalable DNS Service Discovery (dnssd) >> -------- >> Current Status: Proposed WG >> >> Chairs: >> Ralph Droms >> Tim Chown >> >> Assigned Area Director: >> Ted Lemon >> >> Mailing list >> Address: dnssd...@ietf.org >> To Subscribe: dnssdext-requ...@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/dnssdext >> >> Charter: >> >> Background >> -- >> >> Zero configuration networking protocols are currently well suited to >> discover services within the scope of a single link. In particular, >> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes >> referred to using Apple Computer Inc.'s trademark, Bonjour) are >> widely used for DNS-based service discovery and host name resolution >> on a single link. >> >> The DNS-SD/mDNS protocol suite is used in many scenarios including >> home, campus, and enterprise networks. However, the zero configuration >> mDNS protocol is constrained to link-local multicast scope by design, >> and therefore cannot be used to discover services on remote links. >> >> In a home network that consists of a single (possibly bridged) link, >> users experience the expected discovery behavior; available services >> appear because all devices share a common link. However, in multi-link >> home networks (as envisaged by the homenet WG) or in routed campus or >> enterprise networks, devices and users can only discover services on >> the same link, which is a significant limitation. This has led to >> calls, such as the Educause petition, to develop an appropriate service >> discovery solution to span multiple links or to perform discovery across >> a wide area, not necessarily on directly connected links. >> >> In addition, the "Smart Energy Profile 2 Application Protocol Standard", >> published by ZigBee Alliance and HomePlug Powerline Alliance specifies >> the DNS-SD/mDNS protocol suite as the basis for its method of zero >> configuration service discovery. However, its use of wireless mesh >> multi-link subnets in conjunction with traditional routed networks will >> require extensions to the DNS-SD/mDNS protocols to allow operation >> across multiple links. >> >> The scenarios in which multi-link service discovery is required may >> be zero configuration environments, environments where administrative >> configuration is supported, or a mixture of the two. >> >> As demand for service discovery across wider area routed networks >> grows, some vendors are beginning to ship proprietary solutions. It >> is thus both timely and important that efforts to develop improved, >> scalable, autonomous service discovery solutions for routed networks >> are coordinated towards producing a single, standards-based solution. >> >> The WG will consider the tradeoffs between reusing/extending existing >> protocols and developing entirely new ones. It is highly desirable >> that any new solution is backwardly compatible with existing DNS-SD/mDNS >> deployments. Any solution developed by the dnssd WG must not conflict >> or interfere with the operation of other zero-configuration service and >> naming protocols such as uPnP or LLMNR. Integration with such protocols >> is out of scope for this WG. >> >>
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 7 Sep 2013, at 04:05, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote: >> From: Scott Brim > >> The encapsulation is not much of an obstacle to packet examination. > > There was actually a proposal a couple of weeks back in the WG to encrypt all > traffic on the inter-xTR stage. > > The win in doing it in the xTRs, of course, is that you don't have to go > change all the hosts, application by application: _all_ traffic, of any kind, > from that site to any/all other sites which are encryption-enabled, will get > a certain degree of confidentiality. > > Does this count as something the IETF can do reasonably quickly that will > help somewhat? :-) It certainly wouldn't hurt :) Tim
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 6 Sep 2013, at 21:32, Roger Jørgensen wrote: > On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote: >> The IETF focused on developing protocols (and reserving the necessary >> network numbers) to facilitate direct network peering between private >> individuals, it could make it much more expensive to mount large-scale >> traffic interception attacks. > > Think there are work being done on the topic? However, how are you > going to interconnect all of this private peerings? It sort of imply > that everyone need to have their own netblock they can exchange with > others. Mobile IPv6 gives one way to run multiple devices in one subnet. Someone needs to be the HA though. And/or if future homes have multiple /64's, it's not infeasible to dedicate one or more to virtual/overlay LANs. Tim
Re: Rude responses (sergeant-at-arms?)
Isn't there supposed to be a sergeant-at-arms to handle inappropriate behaviour on this list? Though the last I recall that was Jordi, and that was probably ten years ago... Though it would be preferable if everyone were a bit more respectful of other posters, whether new or veteran. Tim
Re: IETF 88 - Registration Now Open!
On 23 Aug 2013, at 18:49, manning bill wrote: > and the hotel is fully booked…. I guess it got fixed Bill, though I only booked for the meeting week itself. tim > > /bill > > > On 23August2013Friday, at 6:36, IETF Secretariat wrote: > >> 88th IETF Meeting >> Vancouver, BC, Canada >> November 3-8, 2013 >> Host: Huawei >> >> Meeting venue: Hyatt Regency Vancouver: >> http://vancouver.hyatt.com/en/hotel/home.html >> >> Register online at: http://www.ietf.org/meetings/88/ >> >> 1. Registration >> 2. Visas & Letters of Invitation >> 3. Accommodations >> 4. Companion Program >> >> >> 1. Registration >> A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC >> 24:00 >> B. After Early-Bird cutoff - USD 800.00 >> C. Full-time Student Registrations - USD 150.00 (with proper ID) >> D. One Day Pass Registration - USD 350.00 >> E. Registration Cancellation >> Cut-off for registration cancellation is Monday, >> 28 October 2013 at UTC 24:00. >> Cancellations are subject to a 10% (ten percent) >> cancellation fee if requested by that date and time. >> F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local >> Vancouver time. >> G. On-site Registration starting Sunday, 3 November 2013 at 1100 local >> Vancouver time. >> >> 2. Visas & Letters of Invitation: >> Information on Visiting Canada, please visit: >> http://www.cic.gc.ca/english/visit/index.asp >> >> After you complete the registration process, you can request an electronic >> IETF letter of invitation as well. The registration system also allows for >> you to request a hard copy IETF letter of invitation. You may also request >> one at a later time by following the link provided in the confirmation email. >> >> Please note that the IETF Letter of Invitation may not be sufficient for >> obtaining a visa to enter Canada. >> >> 3. Accommodations >> The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, >> the meeting venue, as well as at the overflow hotel Fairmont Hotel >> Vancouver, which is located across the street from the Hyatt. >> Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel >> room tax, GST and Destination Management Fee) are excluded from the >> guestroom rate and are subject to change. Room rates DO NOT include daily >> breakfast. >> >> Reservations Cut off Date: >> Hyatt Regency Vancouver - 20 October 2013 >> Fairmont Hotel Vancouver - 11 October 2013 >> >> For additional information on rates and policies, please visit: >> http://www.ietf.org/meetin/88/hotel.html >> >> 4. Companion Program >> If you are traveling with a friend or family member over 18 years of age you >> can register them for the IETF Companion Program for only USD 25.00 >> >> Benefits include: >> - A special welcome reception for companions from 1630-1730 on Sunday, 3 >> November >> - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, >> 3 November >> - A distinctive meeting badge that grants access to the venue (not to be >> used to attend working sessions) >> - Participation in a separate companion email list if you choose to help >> communicate and make plans with other IETF Companions. >> >> You can register your companion at any time via the IETF website or onsite >> at the meeting. >> >> To join the 88 companions mailing list only see: >> https://www.ietf.org/mailman/listinfo/88companions >> >> Only 71 days until the Vancouver IETF! >
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
On 4 Aug 2013, at 20:53, "John Levine" wrote: >> If there is a serious drive to discontinue the weekly posting >> summary - I strongly object. > > As far as I can tell, one person objects, everyone else thinks it's fine. > > Seems like rough consensus to me. And the code is running… Tim
Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))
On 27 Jul 2013, at 02:20, Phillip Hallam-Baker wrote: > If I had known this was taking place I might have made the trip to Berlin. > > I am very interested in the problem this tries to solve. I think it is the > wrong way to go about it but I am interested in the problem. > > The case for having some sort of local name discovery mechanism is clear in > both the enterprise and the home network. The case for that discovery > mechanism responding to DNS queries in the local namespace is equally clear. > > Thinking of this problem as how to clients configure their DNS entries is > completely the wrong way to go about it. Setting up a new network service > requires more than poking the DNS with a stick. Phil, comments on draft-lynn-mdnsext-requirements are very welcome. There should be a jabber realy who can forward remote comments to the mic. Tim
Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))
On 26 Jul 2013, at 23:31, John C Klensin wrote: > --On Friday, July 26, 2013 22:48 +0100 Tim Chown > wrote: >> >> That means the charter agreed from the bashing of the draft >> charter in the previous 40 minutes, not that a charter is >> already agreed. > > If there is something to be bashed for those 40 minutes, I'd > expect a link to at least a skeleton first draft. I note that > draft charter does have a link from the meeting materials page, > just not from the agenda. But, modulo the comment below, that > is a matter of taste to be working out between you, Ralph, and > the IESG. The draft charter was placed where they usually are, on the BoF wiki. But I added a link to a specific draft charter file when I updated the agenda, see https://datatracker.ietf.org/meeting/87/agenda/dnssdext/. The other "problem" for mdnsext is that the second BoF has been given a different name, for various reasons, but that does make it a bit harder to locate the mail list and draft. >> True. Though the chair names are on the posters linked in the >> materials page, which I assume is well-advertised to newcomers >> as access to slides is rather important. > > As far as I know, the only "advertisement" is the link from the > "Agendas and Meeting Materials" section of the main meeting page > and the similar links from the Meetings entry on the IETF home > page. Now I'd personally like to see the "New Attendees" > category on the main meeting page changed to "New Attendees and > Participantes" and then including a link to a page that would > give hints about where these things are and how to navigate > around them. But that fairly clearly won't happen before Sunday > and YMMD. Well, I would certainly agree that the meeting materials page/area needs to be well advertised, if it isn't already, but I don't know what additional information newcomers are pointed at, not being one. >> And also on the BoF wiki, which you should know about. > > Yep. I know about it and where to find it. But, as I explained > in my note to Brian, I'm a lot more concerned about newcomers > and remote participants without years or experience than I am > about what I can find if I remember all of the reasonable places > where I might look. While we/you can try to guess what the problems are, it may be better to surveymonkey those who registered as newcomers in a couple of weeks and ask them about their experience, whether they were aware of certain things, and what could be done better. Tim
Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))
On 26 Jul 2013, at 21:48, John C Klensin wrote: > > > --On Friday, July 26, 2013 11:29 -0700 SM > wrote: > >> POSH has not published a session agenda. However, the BoF is >> listed on the meeting agenda. Is the BoF cancelled or will >> this be one of those willful violations of IETF Best Current >> Practices? > > On a similar note, according to its agenda, the core of the > DNS-SD Extensions BOF (dnssdext) is apparently > draft-lynn-sadnssd-requirements-01. The link from the agenda > page [1] yields a 404 error and attempts to look up either > "draft-lynn-sadnssd-requirements" or the author name "lynn" in > the I-D search engine yield nothing. Hi John, Apologies for this. The correct draft name, and the BoF chair contacts, are now in the agenda file at: https://datatracker.ietf.org/meeting/87/agenda/dnssdext/ > FWIW, I also note that the posted agenda is heavily dependent on > the Chairs and mentions an "agreed charter". That means the charter agreed from the bashing of the draft charter in the previous 40 minutes, not that a charter is already agreed. > I am mentioning this on the IETF list only because it is another > example of the point that I (and probably SM and others) are > trying to make: If we are interested in newcomers, remote > participants without years of IETF experience, and/or increased > diversity, we should not allow these kinds of issues to become > requirements for "treasure hunts" or other sorts of obstacles in > people's paths. True. Though the chair names are on the posters linked in the materials page, which I assume is well-advertised to newcomers as access to slides is rather important. And also on the BoF wiki, which you should know about. The names were just missing from the agenda file itself. Tim
Re: BOF posters in the welcome reception
On 26 Jul 2013, at 07:36, Abdussalam Baryun wrote: > On 7/24/13, John C Klensin wrote: >> >> --On Wednesday, July 24, 2013 09:22 +0300 IETF Chair >> wrote: >> >>> I wanted to let you know about an experiment we are trying out >>> in Berlin. >>> ... >>> But we want as many people as possible to become involved in >>> these efforts, or at least provide their feedback during the >>> week. So we have given an opportunity for the BOFs to display >>> a poster in the Welcome Reception (Sunday 5pm to 7pm). If you >>> are attending the reception, take a look at the posters and >>> look for topics that interest you. > > What about each poster state which WG/RFCs it is mostly > depending-on/related (if applicable), this can make an easier way to > know if I am interested or should be interested. The poster deadline passed some time ago. The easiest way to decide if you're interested though is to read the poster, assuming it is well-written :) The conference-style poster idea came up quite late this year. It's a good idea, and is hopefully something that can be improved for IETF88 and beyond. I suspect the idea arose from IETF87 having an unusually high number of BOFs. Tim
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
On 24 Jul 2013, at 16:18, Jari Arkko wrote: > Janet, > >> I am another remote participant who would like to be able to subscribe to >> the meeting-specific mailing list. >> >> I can skip (myself) the ones about coffee and cookies, but definitely want >> to read the ones about schedule changes, etc. >> >> And even the other messages give me a taste of "what it would be like to be >> there". > > Understood. I'm wondering if this points to a need to get on the meeting list > easily. Either without registering, or having a registration flag of being > interested in the meeting while not intending to be there. > > We could create another mailing list too, but I'm a little sensitive for > creating many slightly different mailing lists (duplicate messages, posting > accidentally on the wrong one, etc) I see no reason why the 87attend...@ietf.org list shouldn't be open to remote participants. Is that not the case already? We should be doing all we can to encourage participation. I would share the concerns of duplication if an 87rem...@ietf.org list were set up, but it might be useful for those who aren't there to be able to discuss issues, tips, etc with remote participation. A lot of meeting topics do come up on the main ietf list too, of course. Tim
Re: IETF 87 Registration Suspended
On 5 Jul 2013, at 15:30, John C Klensin wrote: > --On Friday, July 05, 2013 07:40 +0100 l.w...@surrey.ac.uk wrote: > >> It strikes me that 'membership fees' as opposed to 'entrance >> fees' could work around this payment issue. Or incur a >> different tax... > > But the use of a term like "membership fee" has profound > implications for what the IETF claims is our way of doing > business. I would add also that many organisations (and funding bodies) would not support claims for "membership fees" where conference meeting registration fees are perfectly accepted. Tim
Berlin BoFzilla
So I was looking at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart to check the sdnssd BoF text, and was surprised to see a total of 15 proposed BoFs. That seems to be something of a record? That people are coming to the IETF with proposals to do work is probably a healthy thing; it would be more worrying if there were no BoFs proposed. But if all the proposals are accepted, and they all lead to WGs being formed, that's a lot of new groups to be created, scheduled and supported. In contrast, how many WGs have been closed in the past few months? I see there's http://trac.tools.ietf.org/wg/concluded from which I can see there are 10 WGs listed there which seem to have closed this year: iri 2013-01-19 imapmove 2013-01-31 csi 2013-02-12 sipclf 2013-02-20 bliss 2013-02-27 simple 2013-02-27 fecframe 2013-03-06 krb-wg 2013-03-19 eai 2013-03-19 6tch 2013-04-19 I wonder how the volume and lifetimes of WGs has changed over the years, e.g. the number we have, how quickly they complete their work, etc. Has anyone been looking at this? Tim
Re: Weekly posting summary for ietf@ietf.org
On 7 Jun 2013, at 17:12, joel jaeggli wrote: > On 6/7/13 6:03 PM, Tim Chown wrote: >> >> As another example, the v6ops list has recently also had four threads run >> well over the 100 message count, specifically end to end response time, ULA >> usage, "being careful" about ULAs and the semantic prefix thread. > v6ops had a single draft which attracted ~1100 messages over the course of a > year so this isn't new or unusual over there. A small number of posters tend > to be the majority of the volume on several topics, so if you're reading to > understand the positions of the working group or to measure consensus on the > list some judicious sorting is required. Indeed. Sorting and sifting through 500+ emails about one homenet topic over on 6man was similarly challenging (for the homenet arch text). And many of those long v6ops threads were/are relevant to that. It would be nice to determine some way to keep discussions open, without creating unnecessary volume, and repeating already raised arguments. Maybe the answer isn't email for judging consensus. As an outsider, I've seen the IESG/AD system, which seems to essentially allow positions on drafts to be expressed, and easily viewed at a glance. Maybe that's part of the answer, somehow. Some "position" view on a draft, that people can update/edit as the list discussion goes on, that becomes more useful "at a glance" for WG chairs and document editors? We could continue as is with emails, but I've heard of a number of (very wise and valued) past contributors who no longer express their views, because of the problem of volume. Or maybe it's not a valid concern. Tim
Re: Weekly posting summary for ietf@ietf.org
On 7 Jun 2013, at 16:52, Ted Lemon wrote: > On Jun 7, 2013, at 11:48 AM, Andy Bierman wrote: >> So why not move the signal? >> Put IETF Last Call mail on last-c...@ietf.org and leave this list for >> everything else. > > The discussion still has to happen somewhere. I certainly am not > restricting my meaningful participation in last calls, but even in that case > it is important to be restrained and not get into long fruitless discussions, > which, I am afraid, I am wont to do. It's a significant problem for those who *have* to read the threads, in particular document authors, WG chairs, and ADs. Hats off to them for keeping up with it where they need to. As another example, the v6ops list has recently also had four threads run well over the 100 message count, specifically end to end response time, ULA usage, "being careful" about ULAs and the semantic prefix thread. Of course, a healthy debate is a good thing, as is having an open process for discussion. If we had very few comments that would certainly not be good either. But I fear that some valuable contributions are either being drowned out, or that some people with valuable input are being put off contributing. Tim
Re: financial fun with an IETF Meeting in South America
On 27 May 2013, at 16:37, John R Levine wrote: >> Is this above advice from Tripadvisor correct? > > I believe so, but when I was there a few years ago for the ICANN meeting, > excess cash was not a problem. It wasn't hard to estimate how much cash I'd > need, and whatever was left I spent at the airport. The wine they drink in > Argentina is often better than the stuff they send to the UK (which isn't > bad) and much cheaper. Take some home in your suitcase, even if you have to > pay duty it's a bargain. It's not necessarily so easy over the course of seven days. But I guess we could also just give all our leftover cash to a deserving Argentinian IETF attendee. Fernando may like that approach :) > This still doesn't mean I think a meeting in South America is a good idea, > though. See other messages. I think Jari's views are spot on. There's a bigger picture question to address, regardless of the meeting venues, and not just for that region. Tim
Re: financial fun with an IETF Meeting in South America
On 27 May 2013, at 05:15, "John Levine" wrote: >> The move appears to be related to new, restrictive >> regulations the Argentine government has imposed on currency exchanges.' >> According to the Telegraph, 'The new regulations required anyone wanting >> to change Argentine pesos into another currency to submit an online >> request for permission to AFIP, the Argentine equivalent of HM Revenue & >> Customs. ..." > > This isn't likely to change soon. Going into the country isn't the problem, more importantly it seems that if you don't spend all your pesos in Argentina, you can't change them back to your own currency: http://www.tripadvisor.co.uk/Travel-g294266-s601/Argentina:Banks.And.Money.html (see last paragraph) I just keep a pool of Euros and dollars (US and Canadian) which I never change back to my own currency, as I visit these countries a fair bit, but it is a concern to pick a venue where any cash I get in advance is lost if unspent. Is this above advice from Tripadvisor correct? Tim
Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)
Yes, thanks all - I think we're nearly there… Tim On 13 May 2013, at 02:58, Liubing (Leo) wrote: > Hi, Robert > > Your careful review and comments really helped improving the document a lot. > Many thanks to you. > > All the best, > Bing > >> -Original Message- >> From: Robert Sparks [mailto:rjspa...@nostrum.com] >> Sent: Friday, May 10, 2013 11:13 PM >> To: Liubing (Leo) >> Cc: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org; >> gen-...@ietf.org; ietf@ietf.org >> Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt >> (updated for -07) >> >> Thanks Bing - >> >> The updates make the document better, and I appreciate the resolution of >> referencing Tim's expired draft. >> I think you've addressed all my comments except for the one on section >> 5.1, but that's ok. >> >> For completeness and ease on the ADs, here's an updated summary: >> >> Document: draft-ietf-6renum-gap-analysis-05.txt >> Reviewer: Robert Sparks >> Review Date: May 10, 2013 >> IETF LC End Date: April 10, 2013 >> IESG Telechat date: May 16, 2013 >> >> Summary: Ready >> >> >> >> On 5/2/13 6:02 AM, Liubing (Leo) wrote: >>> Hi, Robert >>> >>> Thanks a lot for your continuous careful review. >>> Please see replies inline. >>> -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] Sent: Wednesday, May 01, 2013 12:33 AM To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10, 2013 IESG Telechat date: May 16, 2013 Summary: Ready with nits (that border on minor issues) This update improved the readability significantly, and addressed my major concern about being able to build a list of the gaps. Thank you. There are a few issues from my last call review that are still not addressed. I have left the classification of minor issue vs nits the same as the original review to make referring to the earlier review easier, but please consider all of these Nits. The IESG will need to decide whether to escalate them. I've trimmed away the points that were addressed. On 4/1/13 3:46 PM, Robert Sparks wrote: > -- > Minor issues: > > The document currently references > draft-chown-v6ops-renumber-thinkabout several times. > That document is long expired (2006). It would be better to simply > restate what is > important from that document here and reference it only once in the > acknowlegements > rather than send the reader off to read it. This version still references that long expired draft. There was also conversation on apps-discuss about making that reference normative. IMHO, this is not the right way to treat the RFC series, and strongly encourage moving the text that you want to reference into something that will become an RFC. >>> [Bing] Maybe Brian's suggestion of putting some texts into an appendix is a >> good way. We'll discuss this problem when make the next time update. >>> > Should section 8 belong to some other document? It looks like > operational renumbering > advice/considerations, but doesn't seem to be exploring renumbering > gaps, except for > the very short section 8.2 which says "we need a better mechanism" > without much explanation. Afaict, this wasn't addressed at all. In particular, "we need a better mechanism" is still all that section 8.2 says. >>> [Bing] Sorry for leaving it out. Will do in next update. >>> > Section 5.1, first bullet. The list below "the impact of ambiguous M/O > flags" says things like > "there is no standard" and "it is unspecified". I think you are trying > to say that there is > ambiguity in what's written, not that nothing's written. This entire > list would benefit from > being recast in terms of what needs to be done (what are the gaps?). This text remains unmodified. >>> [Bing] We made revision focusing on explaining "what are the gaps", but >> the texts change was omitted, will do in next update. >>> > -- > Nits/editorial comments: > > There are a few sentences ending with "etc." in the document. Please > consider deleting the > word from the list - it doesn't help each sentence make its point. There were some changes, but mostly t
Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
On 30 Apr 2013, at 16:43, joel jaeggli wrote: > On 4/30/13 8:33 AM, Robert Sparks wrote: >> On 4/2/13 4:58 AM, Brian E Carpenter wrote: >>> Just picking a couple of points for further comment: >>> >>> On 02/04/2013 08:46, Liubing (Leo) wrote: >>>> >>>> [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the >>>> gap analysis. Although the draft is expired, most of the content are still >>>> valid. >>>> draft-chown is a more comprehensive analysis, while the gap draft is >>>> focusing on gaps in enterprise renumbering. So it might not easy to >>>> abstract several points as important from draft-chown to this draft. We >>>> actually encourage people to read it. >>> Robert is right, though, sending people to a long-expired draft is a bad >>> idea. > I'm not sure I see that as worse than referring to Wikipedia, an expired > draft has the property that it's not going to change. I have no problem with > the idea that it would be an informative reference. but yes it's a bit much > to say go read this. >>> Of course we have to acknowledge it, but maybe we should pull some of its >>> text >>> into an Appendix. >>> >>> Tim Chown, any opinion? >> The most recent version (and the one slated for the next telechat) still has >> this long-expired draft referenced. Hi, The old renumbering "thinkabout" draft came out of experiments on IPv6 renumbering we did in 6NET some 10 (yikes!) years ago, for both enterprise and ISP networks. I think most of what was written is still applicable. Brian borrowed a fair deal of it for RFC 5887. I stopped work on it as there was little/no interest in the problem in v6ops at the time (or whatever v6ops was called back then). We produced technical 6NET reports separately, and did some follow-up work with Cisco separately. Personally I don't mind if the principles are mentioned without the explicit reference - an ack in the Acknowledgements is adequate. It would be interesting to review the "thinkabout" draft to see how much still holds true. Glancing at it, sections like "Application and Service-Oriented Issues" are still very much relevant. I guess Stig and I could consider advancing it along the Independent Submission path, or look for publication to an appropriate journal. Life is short :) Tim
Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
On 6 Apr 2013, at 16:39, "Stewart Bryant (stbryant)" wrote: > > On 6 Apr 2013, at 14:04, "Abdussalam Baryun" > wrote: > >> >> If the date is >> special then thoes RFCs SHOULD be *historical*. >> > > Surely the correct requirement is : > > If the date is special then those RFCs MUST be *hysterical*. 'Like' :) Tim
Re: Time zones in IETF agenda
On 6 Mar 2013, at 22:09, Henrik Levkowetz wrote: > > On 2013-02-27 10:20 Tim Chown said the following: >> On 26 Feb 2013, at 20:28, Martin Rex wrote: >> >>> I have a recurring remote participation problem with the >>> IETF Meeting Agendas, because it specifies the time of WG meeting slots >>> in local time (local to the IETF Meeting), but does not give the >>> local time zone *anywhere*. >>> >>> I would appreciate if the local time zone indication would be added >>> like somewhere at the top of the page, to each IETF meeting agenda. >> >> So in this interesting discussion of UTC, Martin has actually made an >> excellent point. Having UTC listings for the agenda would be very >> helpful, or an alternative agenda showing UTC. > > Now available: > > http://datatracker.ietf.org/meeting/agenda-utc Many thanks, as always, Henrik. Tim
Time zones in IETF agenda
On 26 Feb 2013, at 20:28, Martin Rex wrote: > I have a recurring remote participation problem with the > IETF Meeting Agendas, because it specifies the time of WG meeting slots > in local time (local to the IETF Meeting), but does not give the > local time zone *anywhere*. > > I would appreciate if the local time zone indication would be added > like somewhere at the top of the page, to each IETF meeting agenda. So in this interesting discussion of UTC, Martin has actually made an excellent point. Having UTC listings for the agenda would be very helpful, or an alternative agenda showing UTC. Tim
Re: Useful slide tex (was - Re: English spoken here)
On 3 Dec 2012, at 18:11, Fred Baker (fred) wrote: > I agree with the notion that the primary purpose of the meeting is > discussion. What you and I tell those who present in v6ops is that we want > the presentation to guide and support a discussion, and anything that is pure > presentation should take no more than half of the time allotted to them. I > don't see that the tool is the problem, it's the user of the tool, and we all > vary in our presentation/discussion skills. Exactly. If the "presentation" is one slide listing the key changes in the document since the last revision/meeting, and one slide per key question/issue being asked of the room, then that should help facilitate good discussion, not hinder it. What doesn't work is a 15 minute presentation of the current contents of a draft that leaves a couple of minutes for questions. It's not the tool, it's how it's used. And fwiw I think Fred and Joel have done a decent job of this in v6ops, and one of the things that's helped there is trimming out drafts that don't have evidence of a decent level of mail list discussion. Tim
Re: "IETF work is done on the mailing lists"
On 29 Nov 2012, at 18:51, SM wrote: > Hi Ed, > At 06:54 29-11-2012, Edward Lewis wrote: >> Earlier in the thread I saw that someone expressed dismay that BOFs seem to >> be WG's that have already been meeting in secret. I agree with that. At >> the last meeting in Atlanta, I filled in sessions with BOFs and found that >> the ones I chose seemed as if they were already on the way to a >> predetermined solution. Only one had a presentation trying to set up the >> problem to be solved, others just had detailed talks on draft solutions. In >> one there was a complaint that the mail list wasn't very active - not a WG, >> a BOF! Not very engaging. The complaint about a quiet mail list may have been a comment I made at the mdnsext BoF. The reason for that is that the guidance we have for holding a BoF (RFC 5434) recommends forming a public mail list a couple of months before the IETF meeting where the BoF is planned and to have substantive list discussion in advance of the BoF, which should help form a solid problem statement and draft charter. > Extensions of the Bonjour Protocol Suite (mdnsext) BoF > > The agenda [5] mentions "Goals of the BoF" with a link. I don't recall > whether any proposed solution was discussed. Some views on potential solutions were made at the mic in the BoF. But the draft that was presented was a requirements draft, not a solutions one. I'll speak to Ralph soon about moving this forward. >> Bringing in baked work because there are multiple independent and >> non-interoperable solutions is what the IETF is all about. Bringing in a >> baked specification just to get a stamp on it is not. The former is a driver for mdnsext, i.e. a number of vendors producing potentially non-interoperable mDNS proxying solutions. I don't see a problem with the latter, especially if it documents something useful that is otherwise opaque. Certainly some WG lists have a lot of traffic, and on lists it's easy for a small number of vocal people to dominate the discussion, which is less likely to happen face to face (where people have to queue and take turns). Tim
Re: Newcomers [Was: Evolutionizing the IETF]
On 16 Nov 2012, at 13:25, Carlos M. Martinez wrote: > Moving the IETF forward will involve reaching out to other peoples, > other regions, and yes, travel farther away once in a while. I also > understand that we need to do our part in terms of fostering and > increasing the contribution of our region. I said this in an earlier > email and I stand by it. A strength of the IETF is that to participate you can simply join discussions on mailing lists and participate remotely when physical meetings are held. This may mean that for the majority of IETF contributors, the location of the meetings isn't critical, because attendance at every physical meeting isn't required. However, when planning where meetings are held I hope organisers take into account the chairs of the 100+ working groups in the IETF, for whom attendance may not be compulsory but it's certainly highly desirable. If the cost of attending meetings and the complexity of travel goes up, it may become harder to find volunteers willing to take on WG chair and other similar responsibilities for the benefit of the IETF community as a whole. Tim
Re: So, where to repeat? (was: Re: management granularity)
On 7 Aug 2012, at 23:01, Steve Crocker wrote: > I'll bet Dublin would be rated higher if the meetings had been downtown. > Same for Vienna. Quite possibly, but a rating is based on a venue, not a city. Dublin is a great city. An out of town golf resort is not a great venue. Tim > On Aug 7, 2012, at 5:55 PM, Tim Chown wrote: > >> Hi, >> >> My top three repeat venues would be Prague, Minneapolis and Vancouver. >> Great meeting venues, with everything you need nearby. >> >> My least favoured venues have been Dublin, Vienna and Maastricht. >> >> Of course, you have to experiment to find good repeat venues... >> >> Tim >
Re: So, where to repeat? (was: Re: management granularity)
Hi, My top three repeat venues would be Prague, Minneapolis and Vancouver. Great meeting venues, with everything you need nearby. My least favoured venues have been Dublin, Vienna and Maastricht. Of course, you have to experiment to find good repeat venues... Tim
Re: Meeting "lounges" at IETF meetings
On 3 Aug 2012, at 23:38, James Polk wrote: > > To me the exceptional aspects far outweighed the bad things - so I'm chalking > this venue up as one of the best in 13 years of attending IETFs, and a > *serious* contrast to the Paris venue (which I believe was one of the worst - > each time we were there, though the city was nice). +1 Would be fun to get access to an API for the lifts for next time ;) Tim
Re: Meeting "lounges" at IETF meetings
On 3 Aug 2012, at 22:56, Mary Barnes wrote: > The issue that I experienced (and why I'm fussing) is that if you were > attending many sessions in the Regency rooms (and moving rooms between > sessions), it was extremely difficult to weave your way through the corridor > as many people were having their discussion directly in the middle of the > corridor. There just was not room in that corridor for side conversations. > The situation was made worse as that corridor was where they served the > refreshments. And trying to ask people politely to move generally had no > impact in my experience as people were too engaged in their conversations. The corridor congestion when food was served was the only minor nit in an otherwise excellent meeting. The wireless, the facilities etc were all top notch. Tim
Re: Future Handling of Blue Sheets
The registration number links to a registration that includes an email address, should that need to be looked up for some reason later. Holding minimal information for the purpose, and keeping that information as non-identifiable to the holder as possible, would be nice properties? Tim On 17 Jun 2012, at 08:36, Yoav Nir wrote: > This creates a distinguished identity, so if two "Fei Zhang"s attended in > Paris (only case I found in the attendee list), this would distinguish which > of them attended a particular meeting. It would not, however, tie them to an > identity on the mailing list, or to the "Fei Zhang" who attends the Vancouver > meeting, so I'm not sure what purpose it serves. > > Yoav > > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim > Chown > Sent: 16 June 2012 13:54 > To: Joel jaeggli > Cc: IETF Chair; IETF; ietf-boun...@ietf.org > Subject: Re: Future Handling of Blue Sheets > > If the purpose is simply differentiation of people with the same names, could > we not ask people to enter the last four digits of their IETF registration > number, which would presumably be unique, while being easy to remember? The > number could even be on your badge to always be easy to look up. > > Unless there's some reason to keep registration numbers private? > > That would also allow poorly handwritten names to more readily be > checked/corrected by OCR when the sheets are scanned. > > Tim > > On 16 Jun 2012, at 04:50, Joel jaeggli wrote: > >> On 6/15/12 14:42 , edj@gmail.com wrote: >>> I presume it is the same data that people input into the "Organization" >>> field when they register for the meeting. >> >> I do change mine based on what capacity I'm attending a particular >> meeting in. That goes for email address on existing blue sheets as well... >> >> The nice people who send me a check every two weeks don't generally >> fund my attendance. >> >>> Regards, >>> >>> Ed J. >>> >>> -Original Message- >>> From: Eric Burger >>> Sender: ietf-boun...@ietf.org >>> Date: Fri, 15 Jun 2012 17:37:50 >>> To: IETF Chair >>> Cc: IETF >>> Subject: Re: Future Handling of Blue Sheets >>> >>> Do we have guidelines as to what is an "organization affiliation"? >>> >>> On Jun 14, 2012, at 5:26 PM, IETF Chair wrote: >>> >>>> Two things have occurred since the message below as sent to the IETF mail >>>> list. First, we got a lawyer in Europe to do some investigation, and the >>>> inclusion of the email address on the blue sheet will lead to trouble with >>>> the European privacy laws. Second, Ted Hardie suggested that we could >>>> require a password to access the scanned blue sheet. >>>> >>>> Based on the European privacy law information, the use of email will >>>> result in a major burden. If the email address is used, then we must >>>> provide a way for people to ask for their email address to be remove at >>>> any time in the future, even if we got prior approval to include it. >>>> Therefore, I suggest that we collect organization affiliation to >>>> discriminate between multiple people with the same name instead of email >>>> address. >>>> >>>> Based on Ted's suggestion, I checked with the Secretariat about using a >>>> datatracker login to download the scanned blue sheet. This is fairly easy >>>> to do, once the community tracking tools are deployed. However, with the >>>> removal of the email addresses from the blue sheets, it is unclear that >>>> there is any further need for password protection of these images. >>>> Therefore, I suggest that we proceed without password protection for the >>>> blue sheet images. >>>> >>>> Here is a summary of the suggested way forward: >>>> >>>> - Stop collecting email addresses on blue sheets; >>>> >>>> - Collect organization affiliation to discriminate between multiple >>>> people with the same name; >>>> >>>> - Scan the blue sheets and include the images in the proceedings for >>>> the WG session; >>>> >>>> - Add indication to top of the blue sheet so people know it will be >>>> part of the proceedings; and >>>> >>>> - Discard paper blue sheets after scanning.
Re: Future Handling of Blue Sheets
If the purpose is simply differentiation of people with the same names, could we not ask people to enter the last four digits of their IETF registration number, which would presumably be unique, while being easy to remember? The number could even be on your badge to always be easy to look up. Unless there's some reason to keep registration numbers private? That would also allow poorly handwritten names to more readily be checked/corrected by OCR when the sheets are scanned. Tim On 16 Jun 2012, at 04:50, Joel jaeggli wrote: > On 6/15/12 14:42 , edj@gmail.com wrote: >> I presume it is the same data that people input into the "Organization" >> field when they register for the meeting. > > I do change mine based on what capacity I'm attending a particular > meeting in. That goes for email address on existing blue sheets as well... > > The nice people who send me a check every two weeks don't generally fund > my attendance. > >> Regards, >> >> Ed J. >> >> -Original Message- >> From: Eric Burger >> Sender: ietf-boun...@ietf.org >> Date: Fri, 15 Jun 2012 17:37:50 >> To: IETF Chair >> Cc: IETF >> Subject: Re: Future Handling of Blue Sheets >> >> Do we have guidelines as to what is an "organization affiliation"? >> >> On Jun 14, 2012, at 5:26 PM, IETF Chair wrote: >> >>> Two things have occurred since the message below as sent to the IETF mail >>> list. First, we got a lawyer in Europe to do some investigation, and the >>> inclusion of the email address on the blue sheet will lead to trouble with >>> the European privacy laws. Second, Ted Hardie suggested that we could >>> require a password to access the scanned blue sheet. >>> >>> Based on the European privacy law information, the use of email will result >>> in a major burden. If the email address is used, then we must provide a >>> way for people to ask for their email address to be remove at any time in >>> the future, even if we got prior approval to include it. Therefore, I >>> suggest that we collect organization affiliation to discriminate between >>> multiple people with the same name instead of email address. >>> >>> Based on Ted's suggestion, I checked with the Secretariat about using a >>> datatracker login to download the scanned blue sheet. This is fairly easy >>> to do, once the community tracking tools are deployed. However, with the >>> removal of the email addresses from the blue sheets, it is unclear that >>> there is any further need for password protection of these images. >>> Therefore, I suggest that we proceed without password protection for the >>> blue sheet images. >>> >>> Here is a summary of the suggested way forward: >>> >>> - Stop collecting email addresses on blue sheets; >>> >>> - Collect organization affiliation to discriminate between multiple people >>> with the same name; >>> >>> - Scan the blue sheets and include the images in the proceedings for the WG >>> session; >>> >>> - Add indication to top of the blue sheet so people know it will be part of >>> the proceedings; and >>> >>> - Discard paper blue sheets after scanning. >>> >>> Russ >>> >>> >>> On May 6, 2012, at 12:46 PM, IETF Chair wrote: >>> We have heard from many community participants, and consensus is quite rough on this topic. The IESG discussed this thread and reached two conclusions: (1) Rough consensus: an open and transparent standards process is more important to the IETF than privacy of blue sheet information. (2) Rough consensus: inclusion of email addresses is a good way to distinguish participants with the same or similar names. Based on these conclusions, the plan is to handle blue sheets as follows: - Continue to collect email addresses on blue sheets; - Scan the blue sheet and include the image in the proceedings for the WG session; - Add indication to top of the blue sheet so people know it will be part of the proceedings; and - Discard paper blue sheets after scanning. On behalf of the IESG, Russ >>> >> >> > >
Re: Future Handling of Blue Sheets
On 23 Apr 2012, at 06:48, Tobias Gondrom wrote: > On 23/04/12 13:41, Joel jaeggli wrote:. >> >> What property of the blue sheet makes it personal data. > > The fact that publishing them will allow to track in which location (i.e. > meeting room) you are/were at a given point in time. Basically a person could > track your movement over the time of the IETF week. I thought one main purpose of blue sheets was to size the rooms appropriately. If people stop signing the sheets due to privacy concerns, and I would expect many to do so if this change is made, we might be seeing a few cramped rooms. Tim
Re: primary Paris hotel booking
On 20 Jan 2012, at 00:37, Stuart Cheshire wrote: > > Good suggestion Brian. > > I just called our corporate travel department and got the same rate as IETF, > including free Internet and breakfast, and "cancel by 6 PM on check-in day". Nice if you have such a department :) I booked a room by fax and the email confirmation took 11 days to arrive, so don't expect a quick turnaround. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
On 23 Oct 2011, at 18:28, Loa Andersson wrote: > Nurit, > > I'm in the same situation, but part of the argument is right. > > If we do one North America, one Europe and one Asian meeting > per year; places like Minneapolis and Phoenix is cheaper regardless > where you come from. That is if you compare with high end cities > like SF, NY AND DC. ALso places where you need an extra hop to get > there. +1 for Minneapolis and Prague. Relatively large travel hubs, good venues and cheap hotels. But I understand the need to spread the venues. I recall reading thelatest attempt to secure an Asian venue led to Vancouver? Perhaps WG chairs may consider more seriously not holding WG sessions if the agendas are very light? At the very least that might solve the Friday problem. But a lot is always done out of WG sessions too, which is hard to put a value on. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 25 Aug 2011, at 14:58, Nathaniel Borenstein wrote: > > I'm not saying this is the whole problem -- and it would be interesting to > graph US meetings separately -- but the weakness of the dollar has to be a > factor. -- Nathaniel The graphs are really interesting, but the fact remains you can book a room for a week at Minneapolis or Prague in IETF82 week for nearly $100 a day less than the cost of the Hyatt in Taipei, and that's just the public hotel rate, nothing negotiated. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On 24 Aug 2011, at 21:58, Donald Eastlake wrote: > On Wed, Aug 24, 2011 at 4:28 PM, Geoff Mulligan > wrote: >> >> ... >> >> You could pick Rosemont, IL (next to O'hare) for every meeting (oops, >> sorry - misses on decent food). > > Minneapolis or Chicago, one place doesn't make it. The policy of the > IETF has been to meet where the attendees come from, although with > some projection into the future. So I thought we were currently trying > to equalize meetings in North America, Europe, and Asia. So it is an > absolute minimum of three places. That's a fair point, and the three region split is in principle the right thing to do. But I think Taipei's prices are the highest I've seen for the venue hotel, and the organising committee should take note of the comments about that, and the cancellation policy, for future venue selections. I am also a fan of Minneapolis. I just looked at Hilton IETF venue prices there for the IETF82 week. There are king rooms under $200 a night direct from the hotel with a good cancellation policy, and that's without any negotiated price. That's a $500-$600 difference in cost over the 5-6 nights people would typically stay. I'm interested in how much sponsors contribute, and how that compares to $500 less in hotel fees over a week times 1,200 attendees. The Hilton Prague also has rooms at $200 the same week. The idea of exploring a university campus is an interesting one. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IPv6Support Required for all IP-capable nodes) to Proposed Standard
On 22 Aug 2011, at 23:53, Brian E Carpenter wrote: > +1 to Ned. I can't see why this draft seems to make some people > go defensive - it isn't saying "IPv4 is evil" or anything silly > like that, it's just saying "IPv6 is the future". > > RFC1122v6 is another matter entirely. We clearly aren't ready > for it yet, but draft-ietf-6man-node-req-bis is a step on the way. I agree with Ned and Brian. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Oh, and *after* you book, it says Additional Charges 10.000 Percent service charge So the charge is 10% higher than what's displayed. It would be nice if the full charge was more up front. People checking for budget in advance may be unaware of this. Tim On 23 Aug 2011, at 13:22, Tim Chown wrote: > The room rate I see is 8500 TWD, which is $293 a night. That is a Grand > King room, for 2 people. > > If you don't put G-23ET in the corporate/group box, it gets much worse! I'm > guessing the web link on the IETF site should read > http://taipei.grand.hyatt.com/hyatt/hotels/index.jsp?extCorporateId=G-23ET to > simplify that? > > On the plus side, flying out from Europe the time zones mean I don't need to > stay Saturday night, so that actually puts the total hotel cost down, since > the stay is 5 nights not the usual 6 (remembering that you need to fly in/out > including a Saturday night for the cheaper flight). > > Tim > > On 23 Aug 2011, at 12:57, Thomas Nadeau wrote: > >> >> >> >> >> On Aug 23, 2011, at 1:34 AM, John C Klensin wrote: >> >>> >>> >>> --On Monday, August 22, 2011 20:16 -0400 Ray Pelletier >>> wrote: >>> >>>> ... >>>> As for the rates, they are high. Taiwan is expensive, >>>> particularly given that the hotels know what our options are >>>> when we book the TICC. The Hyatt knew that foreign visitors >>>> needed to use the Hyatt as headquarters and charged >>>> accordingly. Since the time of our site visit, 2 new hotels >>>> have been constructed in the vicinity of the TICC (Le Meridien >>>> and W), which may provide more competition for Hyatt in these >>>> circumstances. At the time we were working on this event, >>>> there were no acceptable options. >>> >>> Ray, >>> >>> I know you want to find sponsors and go where the sponsors want >>> to go. I accept the explanation that you negotiated as hard as >>> you could for both room rates and cancellation policies. But I >>> have to wonder, especially in the light of Lixia's observation >>> about the US Govt rate (which, internationally, is often a >>> pretty good measure for the higher end of a reasonable rate in a >>> given city), whether there is a stopping rule. We were told in >>> Quebec that you had given up on one Southeast Asian city because >>> rooms would have cost over USD 300 a night. I don't remember >>> hearing about a sponsor there. What looks like USD 275 net is >>> not all that much less than USD 300, especially if the dollar >>> continues to sink. >>> >>> So, if you had a sponsor for a future meeting at that other >>> location, would an estimated USD 300 be acceptable? USD 350? >>> >>> I obviously don't have all of the information available to me >>> that you and the IAOC do, but it seems to be there is always >>> another alternative. If there are no local ones, that >>> alternative is usually described as "just say no and go >>> elsewhere". What I'm trying to understand, mostly for the >>> future and with the understanding that it is presumably much too >>> late for Taipei and the several following meetings, is whether >>> you would ever consider that an option for a meeting for which >>> you have a sponsor if you hold it in a particular place or if >>> you and the IAOC really believe there is no alternative under >>> those circumstances. >> >> I think we need to adopt a simple rule of thumb whereby we do not book >> venues where room rates of less than $200 USD are unavailable - sponsor or >> otherwise. >> >> Tom >> >> >>> >>> john >>> >>> >>> john >>> >>> >>> ___ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
The room rate I see is 8500 TWD, which is $293 a night. That is a Grand King room, for 2 people. If you don't put G-23ET in the corporate/group box, it gets much worse! I'm guessing the web link on the IETF site should read http://taipei.grand.hyatt.com/hyatt/hotels/index.jsp?extCorporateId=G-23ET to simplify that? On the plus side, flying out from Europe the time zones mean I don't need to stay Saturday night, so that actually puts the total hotel cost down, since the stay is 5 nights not the usual 6 (remembering that you need to fly in/out including a Saturday night for the cheaper flight). Tim On 23 Aug 2011, at 12:57, Thomas Nadeau wrote: > > > > > On Aug 23, 2011, at 1:34 AM, John C Klensin wrote: > >> >> >> --On Monday, August 22, 2011 20:16 -0400 Ray Pelletier >> wrote: >> >>> ... >>> As for the rates, they are high. Taiwan is expensive, >>> particularly given that the hotels know what our options are >>> when we book the TICC. The Hyatt knew that foreign visitors >>> needed to use the Hyatt as headquarters and charged >>> accordingly. Since the time of our site visit, 2 new hotels >>> have been constructed in the vicinity of the TICC (Le Meridien >>> and W), which may provide more competition for Hyatt in these >>> circumstances. At the time we were working on this event, >>> there were no acceptable options. >> >> Ray, >> >> I know you want to find sponsors and go where the sponsors want >> to go. I accept the explanation that you negotiated as hard as >> you could for both room rates and cancellation policies. But I >> have to wonder, especially in the light of Lixia's observation >> about the US Govt rate (which, internationally, is often a >> pretty good measure for the higher end of a reasonable rate in a >> given city), whether there is a stopping rule. We were told in >> Quebec that you had given up on one Southeast Asian city because >> rooms would have cost over USD 300 a night. I don't remember >> hearing about a sponsor there. What looks like USD 275 net is >> not all that much less than USD 300, especially if the dollar >> continues to sink. >> >> So, if you had a sponsor for a future meeting at that other >> location, would an estimated USD 300 be acceptable? USD 350? >> >> I obviously don't have all of the information available to me >> that you and the IAOC do, but it seems to be there is always >> another alternative. If there are no local ones, that >> alternative is usually described as "just say no and go >> elsewhere". What I'm trying to understand, mostly for the >> future and with the understanding that it is presumably much too >> late for Taipei and the several following meetings, is whether >> you would ever consider that an option for a meeting for which >> you have a sponsor if you hold it in a particular place or if >> you and the IAOC really believe there is no alternative under >> those circumstances. > > I think we need to adopt a simple rule of thumb whereby we do not book venues > where room rates of less than $200 USD are unavailable - sponsor or otherwise. > > Tom > > >> >> john >> >> >> john >> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On 28 Jul 2011, at 21:51, Michel Py wrote: > Lorenzo, > >> Lorenzo Colitti wrote: >> http://www.google.com/intl/en/ipv6/statistics/ > > Thanks for the update. > Clarification: in your stats, is AS12322's traffic classified as native > or as 6to4/teredo? Hi, I just ran a search through our Netflow logs of the most recent flows attempting to traverse our enterprise border and this showed: 2002::/16 (6to4): Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 2001::/32 (Teredo): Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M Other: Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M Teredo appears skewed by one host's behaviour which I'll be looking into, otherwise it's about what I'd expect with around 1% by volume being 6to4. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 27 Jul 2011, at 17:03, Mark Andrews wrote: > 0d20eb6-78c9-415d-9493-3aa08faac...@ecs.soton.ac.uk>, Tim Chown writes: >> >> a) use 6to4 anyway on an open platform like OpenWRT > > Which may or may not still have the code. OpenWRT could remove > support just the same as another source could. OpenWRT is also not > widely supported by CPE vendors. i.e. you are own your own if > something goes wrong in most (not all) cases. In the event OpenWRT should remove 6to4 support, just get like-minded people together (if there are lots of people that consciously want to use 6to4 for application development and testing) and roll your own. >> b) use a tunnel broker - this works much better through NATs and with dynamic >> IPv4 addresses > > For which there is only experimental / ad-hoc code. Please name > CPE vendors that support tsp? Please name CPE vendors that support > tunnel re-configuration on re-number. Jeroen has answered this, but I would point out, as an example of what can be done in short time, that I had a student last year who developed a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and QoS support, using a web interface driving existing tools like iptables and tc. He chose to use the HE broker, and it's a one-time registration after which it just works without further user intervention with HE. It would be very interesting to see brokenness figures for well-known broker prefixes as against 6to4, if anyone is gathering such data. >> c) use your $work VPN if it supports IPv6, which it could/should if your comp >> any values IPv6 >> d) get IPv6 from your ISP, or move to one that has it if yours does not > > Which is not always a viable option. It is in the UK, at least. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 27 Jul 2011, at 16:15, Mark Andrews wrote: > > Because it will come down to "run 6to4 and be exposed to some bug" > or "not run 6to4 but be safe from the bug". We already have vendors > saying they are thinking about pulling 6to4 from their code bases > if it becomes historic. I would note that RIPE-501 does not mention 6to4: http://www.ripe.net/ripe/docs/ripe-501 As far as I can see, it only mentions RFC4213. I would ask what is the alternative if as Mark suggests the vendors begin removing 6to4 support? a) use 6to4 anyway on an open platform like OpenWRT b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses c) use your $work VPN if it supports IPv6, which it could/should if your company values IPv6 d) get IPv6 from your ISP, or move to one that has it if yours does not I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On 26 Jul 2011, at 15:14, Tim Chown wrote: > > So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will > further reduce what little use there is of 6to4 now, and happy eyeballs will > mitigate any remaining instances of its use that are bad. So whether 6to4 is > tagged Historic or not, it should be causing significantly less harm. To clarify, I am in favour. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On 25 Jul 2011, at 15:30, Ronald Bonica wrote: > > Please post your views on this course of action by August 8, 2011. Some observations. Our own users made use of 6to4 maybe 8+ years ago, and at the time it was handy to have. Today though we're not aware of any of our users running 6to4 intentionally. We have IPv6 native on site, and anyone who wants home IPv6 connectivity either goes to an ISP that provides it, e.g. A&A in the UK, or they use a tunnel broker. Brokers have the additional benefit of working through NATs and with dynamic IPv4 endpoints. Our site sees about 1-2% of all inbound traffic being IPv6, and of that less than 1% is 6to4, and this is only likely to fall further with rfc3484-bis. What 6to4 we do see is probably reasonably robust in that our return path uses the JANET-provided 6to4 relay. Most operating systems either already, or before long will, support rfc3484-bis, which means hosts should use IPv4 in preference to 6to4 where both are available. To choose to use 6to4, the user would need to consciously change their 3484 policy table, assuming their OS supports that (Linux and Windows do, MacOS X Lion appears not to). Geoff Huston has presented data at IETF80 showing 6to4 brokenness and performance. We now have 'Happy Eyeballs Lite' implemented in Chrome and (I believe, not tested it yet) Firefox, which means the browser can adapt to broken IPv6, whether caused by 6to4 or other factors. The 6to4-advisory draft suggests off-by-default, which I agree with, and use of relays to improve user experience. The problem is we can't expect every site/ISP to run a relay (or multi-address with 6to4) so there will inevitably always be problems with the 3068 mode of 6to4. We measured rogue RAs over a two year period on our wireless network. About 60% of the time at least one host was emitting a rogue 6to4-based RA. While these were mitigated by ramond, it would be good to see vendors fix this; it's not just MS ICS. Happy Eyeballs is a mitigation for such rogue RAs also. So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will further reduce what little use there is of 6to4 now, and happy eyeballs will mitigate any remaining instances of its use that are bad. So whether 6to4 is tagged Historic or not, it should be causing significantly less harm. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reading drafts on an ipad
On 7 Jul 2011, at 03:36, Glen Zorn wrote: > On 7/6/2011 10:38 PM, Cullen Jennings wrote: > >> Has anyone found a particularly good solution to reading drafts on an ipad? >> What about markup and notes on drafts? > > The iPad is a porn toy; get a real computer. You could save drafts as PDF and use GoodReader, which is a very nice app, to annotate comments, etc. You can also fit a lot of drafts on a free DropBox account, which GoodReader works fine with. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Multicast Ping Protocol) to Proposed Standard
I think this draft specifies a very useful protocol, which we have used at our site and which has been a valuable multicast debugging tool. The specification and implementations have evolved over maybe 5-6 years or so. The implementations we've used have been of various stages of the protocol's development. A student at our site implemented an earlier version of the protocol successfully. I don't believe we've used a version at our site based on the spec in the final version of the text, so I can't comment on that specifically. There are some parts of the text that I think indicate the protocol has evolved over a length of time; if it were rewritten from scratch it would probably be somewhat more compact, due to some level of repetition of aspects of the protocol. However, I think it's more important to get the protocol published now, so I would support publishing it as is. The protocol is defined in a fairly loose way, but the core elements are tight enough for implementation. This is reflected in the text at the start of Section 6. I noticed one nit in terms of the client ID. In Section 2 the text says: "At runtime, a client generates a client ID that is unique for the ping test. This ID is included in all messages sent by the client." Then later in the more detailed spec, the text says: "A client SHOULD always include this option in all messages (both Init and Echo Request)." I would have expected the inclusion of the Client ID to be a MUST, based on the earlier explanation. If it is a SHOULD, the introduction text should say "this ID is usually included in all messages sent by the client". It would be nice to consider mechanisms to discover 'public' ssmping test servers, but that's a separate text :) Tim On 20 Jun 2011, at 18:51, The IESG wrote: > > The IESG has received a request from the MBONE Deployment WG (mboned) to > consider the following document: > - 'Multicast Ping Protocol' > 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 > ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Multicast Ping Protocol specified in this document allows for > checking whether an endpoint can receive multicast, both Source- > Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also > be used to obtain additional multicast-related information such as > multicast tree setup time. This protocol is based on an > implementation of tools called ssmping and asmping. > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/ > > > No IPR declarations have been submitted directly on this I-D. > > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 3 Jul 2011, at 12:10, Gert Doering wrote: > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: >> There's clearly a lack of consensus to support it. > > There's two very vocal persons opposing it and a much larger number of > people that support it, but have not the time to write a similarily > large amount of e-mails. For me, this is enough for "rough consensus". > > (And I second everything Lorenzo, Randy and Cameron said - there's > theoretical possibilities, and real world. 6to4 fails the real-world > test. Get over it, instead of attacking people that run real-world > networks for the decisions they need to do to keep the networks running > in a world without enough IPv4 addresses). I'm with Gert, Lorenzo, Randy and others here. It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interest in IPv6 deployment takes part. Thus its view on IPv6 deployment practices should be given due regard. The opposition on the IETF list seemed to be a vocal minority, and of course one person seemed to post a disproportionate number of replies. The problems with 6to4 (20% minimum failure rate, and poor performance when it does connect) are well documented and have led to various 'counter measures' from the IETF, including: a) 6to4 off by default, as per 6to4-advisory b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented already) c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simplistic version is already in Chrome) Those measures indicate how bad a problem 6to4 creates. If we're going to the trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer include 6to4 support at all. I do agree however that the most important point is publishing the -advisory text. As a provider of a (not large) enterprise, I know that a fraction of 1% of connections to our site suffer a 10 second+ delay to a dual-stack web site where they suffer no delay to an IPv4-only one. There's no way to know for sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) should minimise that figure. Having said that, less than 1% of users who connect to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disappear in terms of loss of users, as those users could almost certainly still reach us over IPv4. Our own users who want IPv6 connectivity when offsite use tunnel brokers, which provide a much better (and more predictable) service, one that also works from behind a NAT, which in the reality of home, hotel, and other hotspot networks is quite important. As for operators 'fixing' 6to4, well, I'd rather see operators invest that effort in deploying IPv6, rather than making 6to4 work better, for some value of 'better'. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On 25 Jun 2011, at 05:18, Christian Huitema wrote: > It seems that we have wide consensus to publish the advisory document, not so > much for the "6to4 historic" part. Can we just publish the advisory and be > done with this thread? I'm a little confused by this discussion. I had thought the call here was to solicit 'substantial' comments about -advisory and -historic. Thus I assume people who, like me, are in favour of both drafts progressing are not going to respond to the list at all, which means the list isn't a reflection of consensus - it's not a vote. I do agree with the comment that the call should be identifying new issues, and even if just one person raises several such (valid) issues, they should be considered as part of the process. While I'm now here, my personal view is that -advisory must be progressed and -historic should be progressed. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 21 Jun 2011, at 14:28, Ray Bellis wrote: > > On 21 Jun 2011, at 14:02, Simon Perreault wrote: > >> Not going to argue about "San Diego vs Québec", but just going to point >> out that multiple carriers do serve Québec. Among them are Air Canada, >> United, Continental, Delta, and US Airways. > > The only European operator into YBQ appears to be Air Transat (whoever the > heck they are) and they only fly from Marseille and Paris. > > I'm flying BA to Montreal and taking the short city hopper flight to YBQ from > there. For a single operator trip from the UK to Quebec City, there's Air Canada out of Heathrow. You can go via Montreal or other cities. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Getting to Quebec City
On 18 Jun 2011, at 17:08, John R. Levine wrote: >> As far as renting a car, it is likely a very good choice for anyone that is >> arriving in Montreal later in the day. I have a choice of one direct flight >> to Montreal that puts me arriving in Montreal > 7pm. > > FYI, there is a direct bus from YUL to Quebec that leaves at 20:30. With > Wifi, even. It's a reasonable choice, and about $100 less than a one way car > rental. The Quebec bus station is adjacent to the train station and a quick > taxi to hotels. I'm flying internationally to Montreal and have a connecting flight from there to Quebec City with Air Canada (if they're not on strike, though the planes still to be flying despite that). The connect is listed at 50 mins so is probably about 30-40 in the air. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On 13 Jun 2011, at 16:28, Noel Chiappa wrote: > > If 6to4 has problems, fine, write a document that says something like '6to4 > won't work for a host behind a NAT box because the host won't know it's true > IPv4 global-scope address - so you should also not turn 6to4 on by default' > and fix/publicize the issues. There has been a good deal of work making tunnel brokers work through IPv4 NATs and with changing IPv4 endpoints. Both SiXXS and HE brokers handle such issues, e.g. using a heartbeat method. So these ought to be (relatively) attractive to end users who want IPv6? Presumably the prefixes used by such providers, and others like gogo6, are known so brokenness stats for such services could be deduced? Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
I agree the draft should be progressed, so add another +1 to the 'just ship it' people. On 9 Jun 2011, at 18:39, Keith Moore wrote: > If pain associated with 6to4 provides an additional incentive for ISPs to > deploy native v6, and for users to use native v6 when it becomes available, > that's a Good Thing. The pain though is felt by the content providers, who still see too much brokenness. On 9 Jun 2011, at 19:01, james woodyatt wrote: > I confidently predict the reclassification to Historic will be roundly > ignored not just by Apple product engineering but by the entire industry. > We're smart enough to recognize that we're not the target audience for the > RFC. The draft that matters is the companion advisory draft. It would be > nice if the 6to4-to-historic draft could be spiked so as not to distract from > its companion, but I don't see that as a likely outcome. Alas and alack. Well, the most important point in this is that 6to4 is disabled by default in every device. Apple did that already, which is good. What is unclear to me though is whether deprecating 2002::/16 means that prefix would no longer be routed, as per 3ffe::/16, or just 'reserved' so it's not reallocated later. On 9 Jun 2011, at 19:53, Keith Moore wrote: > On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote: >> Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot >> less time than you have spent writing email on this thread. :-) > > That's who I was using before. Our staff and students find the HE broker easy to use, though I believe some also use other brokers. One student did a final year project this year developing a Linux home router which included HE broker support. It was simple to use/integrate. On 9 Jun 2011, at 19:56, james woodyatt wrote: > I need *native* IPv6 into my home in San Francisco for my day job Have you considered deploying/adding IPv6 VPN support at your day job? So your VPN from home to work gives you IPv4 and IPv6? This is quite a nice model, and is starting to appear in UK universities, and I use it myself for IPv6 training. At least one big vendor offers this today. Users are familiar with VPN use, so adding IPv6 with that comes naturally, and $dayjob provides the support, so you're in control. > Meanwhile, 6to4 works fine on their network so long as remote IPv6 > destinations have a working return path route to 2002::/16, i.e. they are > complying with I-D.ietf-v6ops-6to4-advisory now. That 'so long as' is the crux though. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 8 Jun 2011, at 21:19, Keith Moore wrote: > > Nor, bluntly, is it about a few big content providers or whomever else you > want to label as important. The internet is a hugely diverse place, and you > don't get to dismiss the concerns of people whom you want to label as red > herrings. Again, 40-something percent of the IPv6 traffic that is observed > on the net today uses 6to4. That's about as much as Teredo, it's a hell of a > lot more than native v6. As long as 6to4 is one of the major ways that > people get IPv6 connectivity (and it clearly is), it's premature to declare > 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. Our observation point is as a university on an academic/research network that is native dual-stack. We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected. Hence little if any need for transition methods. This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time. We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since. Perhaps it would be useful to see your use cases more clearly documented with examples. > Almost all usage of IPv6 today is in spite of ISPs. For that matter, a > great many successful IPv4 applications today are deployed in spite of ISPs. > Again, ISPs in general have let us down, and 6to4 and Teredo are carrying > ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 > be deprecated. We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is under 1% of our total IPv6 traffic. I don't know where you see 90%; I assume it's an environment with home-to-home networks, with no broker or IPv6 VPN use? > That's excellent news. But the current proposal on the table to deprecate > 6to4 is premature, confusing, and harmful to real users. The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it? The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from product? > It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 7 Jun 2011, at 07:33, Gert Doering wrote: > > Do we really need to go through all this again? > > As long as there is no Internet Overlord that can command people to > a) put up relays everywhere and b) ensure that these relays are working, > 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. > > If someone wants to use 6to4 to interconnect his machines over an IPv4 > infrastructure (=6to4 on both ends), nobody is taking this away. > > Gert Doering >-- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF web site down for IPv6?
Not having any luck connecting - seems to be an issue near the server: $ traceroute6 www.ietf.org traceroute6 to www.ietf.org (2001:1890:1112:1::20) from 2001:630:d0:f103:216:cbff:fe8b:752e, 64 hops max, 12 byte packets 1 2001:630:d0:f103::2 0.529 ms 0.299 ms 0.321 ms 2 zaphod.6core.ecs.soton.ac.uk 0.283 ms 0.514 ms 0.177 ms 3 ford.6core.ecs.soton.ac.uk 0.564 ms 0.452 ms 0.491 ms 4 2001:630:c1:100::1 0.912 ms 0.970 ms 0.755 ms 5 2001:630:c1:18::a 0.758 ms 0.645 ms 1.550 ms 6 so2-1-0.lond-sbr1.ja.net 3.664 ms 3.601 ms 3.594 ms 7 as0.lond-sbr4.ja.net 3.878 ms 3.995 ms 3.894 ms 8 ix-5-0-0.core4.ldn-london.ipv6.as6453.net 4.093 ms 4.256 ms 4.308 ms 9 if-14-0-0.1874.mcore3.l78-london.ipv6.as6453.net 5.056 ms 5.872 ms 12.121 ms 10 pos7-0.mcore4.njy-newark.ipv6.as6453.net 76.873 ms 77.426 ms 76.838 ms 11 if-12-0.mcore3.njy-newark.ipv6.as6453.net 93.370 ms 104.308 ms 115.081 ms 12 if-9-0-0.906.core3.nto-newyork.ipv6.as6453.net 77.124 ms 77.282 ms 77.030 ms 13 2001:1890:1fff:10a:192:205:35:13 78.233 ms 77.740 ms 77.825 ms 14 * * * 15 * * * Same for others? Hopefully this mail will fall back to IPv4 transport if required. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Mon, Sep 21, 2009 at 07:01:22AM -0700, Ole Jacobsen wrote: > > My personal belief, and the belief of many of have attended meetings > in China is that the fear is unfounded. When I attended APAN24 in China, I felt the discussions in each session were very open. As with the IETF, there was also plenty of good discussions around tables outside the meeting rooms (smoke-free, for the person who asked) and network access seemed open. The meeting agenda contained some of the topics that some posters to this thread seem to have concerns with (see http://www.apan.net/meetings/xian2007/schedule.html). And a lot of very interesting and innovative new application areas. I think the IETF should explore every possibility to host a meeting in China. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning afuture mee ting of the IETF
On Sun, Sep 20, 2009 at 04:19:31PM +0300, Soininen, Jonne (NSN - FI/Espoo) wrote: > Hi, > > I think Steve has captured the core of the issue in this mail. I think his > reasoning is the exact reason why we should go to Beijing with a positive > attitude and have a great meetin in Beijing! > > Cheers, > Jonne. Exactly. I have been to an APAN meeting in Xian. It was superbly organised, the hosts and everyone we met were very friendly. The discussions were very good, some of which were about differences in technology adoption and development between Europe and China, for example. I'd have no hesitation to return for another event any time. Over the years I have personally found that every country I visit expands my understanding and knowledge. People who don't travel perhaps tend to remain more insular. Taking the IETF to China has to be a good thing. BTW getting a visa for China as a UK citizen was very easy, just a simple visit to the London embassy and a 2-hour turnaround on the paperwork. Entering China, at Beijing, was also very painless, perhaps in part due to the investments for the Olympics. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
On Mon, Aug 03, 2009 at 10:09:56AM +0100, Dave Cridland wrote: > > Hmmm... That depends on what you think the shirt means. You imply it > means participation - and I'll vocally resist any definition of > participation which mandates attendance as a part of participation, > since you're implicitly devaluing my participation to somewhere close > to zero - I'll admit I'm no Crocker, Klensin, or Postel, but I > believe my participation is somewhat higher than might be implied by > only having two shirts. (Paris and Prague, if anyone's counting). I have another scenario for draft-ietf-more-t-shirts-please, which is the much loved but heavily faded or worn t-shirt. I really liked my IETF55 sports-style Nokia IPv6 shirt, but it's now relegated to gardening duty. A chance to get a new version would be awesome, and while I doubt we'll do backdated t-shirts, I can imagine the IETF74 shirt we have 'source' for being similarly desirable in five years time. I agree the income to the IETF will not exactly be huge, but more people being seen in IETF shirts is no bad thing for awareness. Often seeing someone else in a past IETF shirt invites a conversation that would never happen otherwise. I also think there's room for non-event shirts, like the i...@20 one. And these t-shirts don't have to be fascimiles - I would be quite happy to order t-shirts in different colours, or even as a polo shirt or in 'female tee' form for a partner. If the IETF chooses to use an appropriate t-shirt company, that sort of bespoke ordering should be possible. Of course I realise this is all work for someone, and there are bigger fish to fry. I would be happy to spend some cycles helping out if volunteers are needed. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
On Wed, Apr 15, 2009 at 08:49:55PM +0200, Michael Tüxen wrote: > Does others also have a problem in reserving a room > at the Clarion Sign? I get only a generic error message > the the system can not process the reservation and > I should check my data... You have to enter Stockholm as the location, but even then I was only offered what seemed to be a single room despite requesting a double room (2 guests). I phoned up and booked that way, which was a little complex (they have a special booking desk for block bookings) and I've yet to receive the email confirmation 24 hours later. But I'm sure it will be OK. Just seems calling is the way to go right now. Tim > On Apr 15, 2009, at 11:49 AM, Iljitsch van Beijnum wrote: > > >On 14 apr 2009, at 16:37, IETF Secretariat wrote: > > > >>Be sure to make your reservation at one of the Stockholm hotels the > >>IETF > >>has a block of rooms held. Cutoff dates for the blocks are > >>relatively > >>early. > > > >No kidding: some are next week. > > > >>Hotel information can be found at: > >>http://www.ietf.org/meetings/75/hotels.html > > > >Some of the phone numbers have a (0) in there. Is this the European > >(0) which means "if you don't know that you sometimes have to remove > >that 0 you will get some unlucky soul on the line who doesn't know > >why he gets so many crank calls" or the North American (xyz) which > >means it's a normal part of the number? > > > >(My phone number in Holland used to be 31073... and it took me years > >to figure out why people would keep calling me over and over again > >when they clearly needed someone else. But this person apparently > >decided that +31(0)73... was a good way to write down their number > >+3173... / 073...) > > > >Do we have an RFC for how to format phone numbers? > >___ > >Ietf mailing list > >Ietf@ietf.org > >https://www.ietf.org/mailman/listinfo/ietf > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Welcome to the "Dnsop-honest" mailing list
And now it's happening for the dnsop list... On Wed, Mar 25, 2009 at 12:43:27PM -0400, dnsop-honest-requ...@lists.iadl.org wrote: > Welcome to the dnsop-hon...@lists.iadl.org mailing list! > > This mailing list is for IETF DNSOP WG members to discuss IETF > business without improper censorship. It does not represent the IETF > but does represent some IETF members. > > This list was created by IADL.ORG (www.iadl.org) because of dishonest > filtering by the IESG. See http://www.av8.net/IETF-watch for more > information on the corrupt activities of officials of the Internet > Society, Inc (ISOC) IETF Activity, and their connection to other > corrupt activities. > > You were probably added to this list because you participated in > dn...@ietf.org discussion, and that list is used to determine > consensus for ISOC IETF Activity actions. Consensus is a democratic > activity of the ISOC, which is a U.S. non-profit, tax exempt > membership corporation. ALL members of the ISOC IETF have a property > right to participate in its democratic decision processes. [see U.S. > v. Local 560, extortion (Hobbs Act) and racketeering by mafia that > took over a Union and tried to prevent participation by those opposing > the mafia] > > Email sent to this list will be forwarded to dn...@ietf.org. Ordinary > IETF members should feel free to unsubscribe from this list if they > choose. IETF representatives (e.g. Working Group Chairs) have a duty > to the corporation to read email sent to them on IETF business, and > should not try to unsubscribe. > > > To post to this list, send your email to: > > dnsop-hon...@lists.iadl.org > > General information about the mailing list is at: > > http://lists.iadl.org/mailman/listinfo/dnsop-honest > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > http://lists.iadl.org/mailman/options/dnsop-honest/tjc%40ecs.soton.ac.uk > > > You can also make such adjustments via email by sending a message to: > > dnsop-honest-requ...@lists.iadl.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > > > Normally, Mailman will remind you of your lists.iadl.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Reverse IPv6 DNS checks on ietf MXs?
Hi, Just an observation, I don't know whether its been changed or applied recently, but we had some mails to various IETF lists soft rejected overnight due to failure of the receiving MX to perform a successful reverse DNS lookup on the IPv6 sender address. - Transcript of session follows - ... while talking to mail.ietf.org.: >>> DATA <<< 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:630:d0:f102:21e:c9ff:fe2e:e915] ... Deferred: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:630:d0:f102:21e:c9ff:fe2e:e915] <<< 554 5.5.1 Error: no valid recipients Warning: message still undelivered after 5 hours Will keep trying until message is 1 week old This was our fault, and we now have a reverse entry for the 'offending' system, but we think this problem was in effect for longer than just last night, when we first noticed the delayed mail warnings, hence we're wondering whether this is a new policy or not on the IETF lists. It's not uncommon for IPv6 servers to be multiaddressed, so mail admins will probably just need to be a wee bit more careful, and certainly try to avoid using autoconf globals on servers.In our case our server acquired an additional global autoconf address on top of its manually configured address, which it started sending from, and as this had no reverse DNS entry we encountered the Rejects. Whether such 'authentication' is still valid for IPv6 systems is of course another question... -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 section 6 rule 9 causing more operational problems
On Wed, Mar 04, 2009 at 02:09:22PM +, Tony Finch wrote: > It seems that Vista implements RFC 3484 address selection, including the > requirement to sort IP addresses. This breaks a great deal of operational > dependence on DNS-based load balancing, as well as being based on an > incorrect understanding of how IP addresses are allocated. > > RFC 3484 needs to be updated to delete this rule, so that the order > returned from the DNS is honoured when the client has no better knowledge > about which address is appropriate. > > See > http://drplokta.livejournal.com/109267.html > http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html > http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html > http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html > http://lists.debian.org/debian-ctte/2007/11/msg00029.html The issue is mentioned in: http://www.watersprings.org/pub/id/draft-arifumi-6man-rfc3484-revise-00.txt "2.5. To disable or restrict RFC 3484 Section 6 Rule 9 There was a discussion at v6ops and ietf@ietf.org mailing lists that the rule 9 of the destination address selection has a serious adverse effect on the round robin DNS technique" However the above has expired. Perhaps Arifumi will issue a new version before the upcoming cutoff. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcement: New Boilerplate Text Required for all new Submissions to IETF
Hi, It would be great if the ietf list could be reminded when the new version of the rather excellent xml2rfc tool is issued, so we don't need to keep checking back for it. Thanks, Tim On Tue, Nov 11, 2008 at 06:03:36PM -0500, Ed Juskevicius wrote: > Greetings. This message is to draw your attention to the significance > of the publication of RFC5377 and RFC5378 earlier today. > > * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be > Granted in IETF Documents > * RFC5378 is Rights Contributors Provide to the IETF Trust > > Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and > RFC5378 obsoletes both RFC3978 and RFC4748. > > Coincident with the above, the IETF Trustees have posted a new policy > document with guidance to the community on: > * Legal Provisions Relating to IETF Documents at > http://trustee.ietf.org/license-info/ > > Taken as a set, the documents listed above specify changes that are now > required in all new submissions into the IETF. > > Henrik Levkowetz has updated the idnit tool and AMS have updated the > Internet-Draft submission tool to reflect the new requirements. An > update to the xml2rfc has been requested. > > Please review the "Legal Provisions Relating to IETF Documents" and > RFC5378 to discover the new boilerplate text that is now required. > Please also take action to update the tools you use for creating your > documents. > > New submissions using either the old or the new boilerplate text will be > accepted starting today, until 01h00 UTC on December 16th, 2008. After > this cutoff date, all new submissions will be required to use ONLY the > new boilerplate text. All submissions using old boilerplate text after > the cutoff date will be rejected. > > Regards and FYI. > > > Ed Juskevicius > IETF Trust Chair > [EMAIL PROTECTED] > > > p.s. - Don't be surprised if you see periodic reminders about this as we > approach December 16th. > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/ietf-announce -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, Nov 10, 2008 at 07:04:27PM +, Tony Finch wrote: > On Mon, 10 Nov 2008, Keith Moore wrote: > > > > okay. I found myself wondering if the change in address space size, and > > in granularity of assignment, might make DNSBLs less reliable. Which is > > a different kind of scalability. > > IPv6's bigger address space affects more security mechanisms than just > DNSBLs, such as defensive port scanning, traffic auditing, etc. > > http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt Thanks Tony - that draft has now emerged as RFC5157: http://www.ietf.org/rfc/rfc5157.txt The granularity of the address space that might appear in a blacklist is an interesting question. I would guess that where today a single IPv4 address appears, a whole IPv6 /64 would be required, at least, since a client on a IPv6 link could in principle use any of the 2^64 available host addresses.But it may be worse, if whole /48's are assigned to DSL users for example (although there seems to be pushback to /56 for SOHO type networks).The question then is whether the single IPv6 address or link it is on is blacklisted, or whether the blacklist includes the 'default' site prefix size. On a related tack, I've been gathering stats on our recorded IPv6 transport mail volumes and identified spam since Dublin, and will analyse these soon and pop out a draft with appropriate observations.We've seen a fairly consistent figure of 50% of our IPv6 transport connections being classified as spam by our MailScanner system since Dublin. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Having a single system for all WG lists has the appeal that whatever process(es) handle the lists, it will be the same for all lists, so you don't have to figure out how N different lists are run. As a shameless plug, we have a free open source solution developed here which is widely used against spam/viruses and that could do the job, see http://www.mailscanner.info/ -- Tim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New web-based submission tool
On Mon, Nov 12, 2007 at 08:53:37AM -0800, Dave Crocker wrote: > > Tim Chown wrote: > >I'd just like to compliment whoever implemented the new web based > >IETF draft submission tool. Very simple to use and rather slick :) > > +10 > > Easy to use, and astonishingly quick release for public access to each new > document. > > Definite home run. I am noticing drafts being published 3 hours after the deadline. I assume that's because the draft is announced when the email ack is done for the submission? I recall having about 3 days to ack before the submitted draft was dropped, which would suggest that we may see drafts appearing until Thursday. But yes, it's very nice. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
New web-based submission tool
Hi, I'd just like to compliment whoever implemented the new web based IETF draft submission tool. Very simple to use and rather slick :) I'd noticed drafts appearing over the weekend rather than in a batch batch as usual this evening. Must be welcomed by the RFC editors too! Cheers, -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Fri, Sep 28, 2007 at 05:29:43PM -0400, Paul Wouters wrote: > On Fri, 28 Sep 2007, Dean Anderson wrote: > > > Maybe its not mentioned because its not a practical solution. But > > whatever the reason it isn't mentioned, a 25 million user VPN is not > > going to happen with 10/8. A comcast person recently complained on PPML > > that there wasn't enough RFC1918 space for their internal network. > > Time for them to migrate to IPv6? :) http://www.6journal.org/archive/0265/ -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: > Ray Plzak wrote: > > The shortage of IPv4 addresses in developing countries in a red herring. > that has to rank as one of the most bizarre statements that's ever been > made on the ietf list. More of an ostrich than a herring? .="""=._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Thu, Sep 13, 2007 at 04:05:09PM +0900, Jun-ichiro itojun Hagino wrote: > > > > > Let me see if I understand this. Without PI, the enterprises say > > > no, and with > > > PI, the ISP's say no. Got it. > > > > I believe that a more constructive assessment is that enterprises are > > unwilling to pay non-trivial costs to renumber, and ISPs are > > unwilling to pay non-trivial costs to support a non-scalable routing > > subsystem. > > my persistent question to the enterprise operator is this: > how frequently do you plan to switch your isp, or how many times > did you do that in the past? > > i have never got any reasonable answer from anyone. OK, I'll bite. Never, and never (in nearly 20 years). Although we in effect have IPv4 PI as being an older university we came online when getting an old Class B was easy, before IP allocations were made from the NREN space. We have renumbered our IPv6 networking as part of experimental/research work (and would from that experience certainly say fully automated renumbering is not possible today), but that was just an academic (and very interesting) exercise. If IPv6 PI were available to us we'd use it because it costs us no extra to do so. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, Jul 31, 2007 at 12:29:51PM -0400, Keith Moore wrote: > > also, publishing an I-D might be useful for other reasons - e.g. to > establish prior art in case an idea or invention in the draft is ever > patented by someone else. I have written or co-written a few drafts in the past purely as problem statements or to raise issues. Rather than repeat text in list discussions, it's 'nice' to have a plain text format statement of an #issue or problem to focus discussion. While the draft may become an RFC, it also quite commonly may not if the solution draft briefly cpatures the issue at hand. Sure, the statement could be a web page, but the IETF 'version control' on texts is also quite handy to see how a text evolved over time. tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, Jul 31, 2007 at 04:51:56PM +0200, Stephane Bortzmeyer wrote: > > To summary: what problem do we try to solve? either reducing ietf costs, or increasing ietf income do we know the 'cost per i-d'? or is that meaningless anyway while the i-d live in the automated part of the process? tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: take the train in Chicago
On Sun, Jul 15, 2007 at 03:55:39PM -, John Levine wrote: > > ... walk from the Palmer House unless it's raining really hard. > > ... If it's raining, So there's me thinking Chicago in July will be mid 80's sunshine, and you mention rain twice in one email :) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Problems with xml.resource.org
Hi, [non xml2rfc users look away] I'm seeing xml.resource.org timing out today, and it seems consistent on one of the two returned IPv4 addresses I see for it (192.20.225.40). $ telnet xml.resource.org 80 Trying 168.143.123.173... Connected to xml.resource.org. Escape character is '^]'. Connection closed by foreign host. But then $ telnet xml.resource.org 80 Trying 192.20.225.40... This seems enough to hamper my attempts to update a draft with xml2rfc. I don't see a contact address for this resource on the web site apart from a mail list. Anyone able to check it? :) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Game theory and IPv4 to IPv6
On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote: > The problem is that until IPv6 has critical mass it is much better to be on > IPv4 than IPv6. > > If there are any grad students reading the list take a look at the game > theory literature and apply it to the transition. Assume that it's a > rat-choice world and that each actor follows their best interest. > > An actor can be in one of several states: > > Unconnected > IPv4 connected with own address > IPv4-NAT connected with NAT address > IPv4/IPv6 connected Dual stack > IPv4-NAT/IPv6 connected Dual stack > IPv6 connected Unfortunately most of the rats cannot choose certain states, so the game is fundamentally flawed. The ISPs are keeping the cheese to themselves. Squeak. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Prague
On Wed, Mar 07, 2007 at 12:23:21PM -0500, Ralph Droms wrote: > I visited Prague about two years ago and had the same experience as Ed. I > traveled via the Metro and on foot, visited all the tourist traps; had no > problems and never felt unsafe. I second that. The metro system was excellent; it would be interesting to know what the closest stop to the hotel is on the metro map: http://www.dpp.cz/download/schema-metra-v-praze.pdf Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Scary technology
On Wed, Nov 01, 2006 at 12:10:16AM -0800, Fred Baker wrote: > if routing protocols aren't scary enough for you... > > http://money.cnn.com/popups/2006/fortune/scary_tech/index.html "Unexpected failure modes led to the early withdrawal of IPv5" -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fw: Why cant the IETF embrace an open Election Process rather than some
Isn't he barred from posting here? On Wed, Sep 13, 2006 at 07:51:27PM -0700, todd glassey wrote: > I am forwarding this on behalf of Dean Anderson. > > > > > Thanks > > > > --Dean > > > > > > On Mon, 11 Sep 2006, Noel Chiappa wrote: > > > > > > From: "todd glassey" <[EMAIL PROTECTED]> > > > > > > > Why cant the IETF and IESG Embrace open elections > > > > > > Because the members are generally happy with the system we have now. > It's > > > called democracy - and you're outvoted. > > > > I think that in fact, members aren't very happy with the system that we > > have now. If they were happy, they wouldn't be changing it. > > > > I think that the system has created a very closed, and very unfair > > management selection process that is not benefiting the members are > > large, but benefiting a few private interests. > > > > > Remember, we had this system for quite a while before the last major > rework > > > of the process (i.e. we'd all seen it in action for some years, and were > able > > > to judge how well was working), and the outcome of that rework was a > > > standards document - i.e. something suject to community approval, i.e. > > > democracy - which made adjustments, but retained the basic framework. If > > > people weren't generally happy with that basic framework, it would have > been > > > obvious at the Last Call of the document. > > > > > > IMO, the IETF has some significant problems, but the process for > selecting > > > people for leadership positions isn't one of them. > > > > I think the IETF and ISOC do have some very significant problems, and > > that those problems are primarilly mismanagement, disloyalty, and > > improper use of the ISOC/IETF/IESG/IAB to benefit the personal and > > adverse interests of the management. The ISOC/IETF employees have > > accrued some torts against the organization for defamation and > > defamatory false reports of member misconduct. > > > > There is plenty of documentation now of disloyalty, fraudulent > > misrepresentation, collusion, and bad faith. To see a little bit, look > > at the Appeal submitted recently to the IAB: > > > > > http://www.av8.net/IETF-watch/Appeal_of_IESG_decision_of_July_10_2006-v4.pdf > > or > > > http://www.av8.net/IETF-watch/Appeal_of_IESG_decision_of_July_10_2006-v4.html > > > > > > > > -- > > Av8 Internet Prepared to pay a premium for better service? > > www.av8.net faster, more reliable, better service > > 617 344 9000 > > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: www.ietf.org unresponsive over IPv6?
On Fri, Sep 01, 2006 at 02:48:10PM +0200, Jeroen Massar wrote: > > How sure are you these have a MTU of 1500? Best way to test is to do > ping6's in the form of "ping6 -M do -s 1500 " and decrementing > per 10 or 20 till it doesn't respond anymore and then increasing again. > > >19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 16. 63ms pmtu 1480 These seem to be OK. > Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug > these issues easier? I'll send the secretariat a separate message about > that, also that they might want to ask Neustar join up with GRH > (http://www.sixxs.net/tools/grh/) to make debugging easier as then we at > least have ASpaths also which might help here. I think that would be helpful. I think IETF could support nice diagnostics if showcasing v6 connectivity. > Check your neighbor cache after the traceroute/path or even a full TCP > connect has completed, you should have an entry similar to: > > [EMAIL PROTECTED]:~$ ip -6 ro sho cache > 2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1 metric 0 > cache expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295 > > The 1480 is noted here, check that that is the case. Well, I can see www.ipv6tf.org fine, but www.ietf.org hangs in the browser, but both seem to negotiate 1480 MTU: For www.ipv6tf.org $ /usr/sbin/tracepath6 www.ipv6tf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::21.231ms 2: zaphod.6core.ecs.soton.ac.uk 4.443ms 3: ford.6core.ecs.soton.ac.uk 1.849ms 4: 2001:630:c1:100::1 1.982ms 5: 2001:630:c1:10::1 2.681ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 7.729ms 10: po2-0.lond-scr.ja.net 9.693ms 11: po0-0.lond-scr4.ja.net10.444ms 12: gi0-1.lond-isr4.ja.net 5.880ms 13: 2001:630:0:10::52 6.636ms 14: uk6x.ipv6.btexact.com 8.269ms 15: uk6x.ipv6.btexact.comasymm 14 11.370ms pmtu 1480 15: v6-tunnel-consulintel.ipv6.btexact.com asymm 16 68.662ms 16: no reply 17: no reply Indicates 1480, and I get the 1480 MTU in my cache: [EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache 2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0 metric 0 cache mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440 2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 557sec mtu 1480 advmss 1440 Then doing the same to www.ietf.org $ /usr/sbin/tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::21.297ms 2: zaphod.6core.ecs.soton.ac.uk 1. 94ms 3: ford.6core.ecs.soton.ac.uk 1.984ms 4: 2001:630:c1:100::1 2. 35ms 5: 2001:630:c1:10::1 2.746ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 3. 16ms 10: po2-0.lond-scr.ja.net 6. 13ms 11: po0-0.lond-scr4.ja.net 5.876ms 12: gi0-1.lond-isr4.ja.net 8.529ms 13: 2001:630:0:10::52 8.918ms 14: ge-2-24.r01.londen03.uk.bb.gin.ntt.net 8.277ms 15: xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net asymm 16 8.742ms 16: xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net asymm 17 8.823ms 17: 1d-uk6x.ipv6.btexact.com 12. 38ms 18: 52.ge0-0.cr2.lhr1.uk.occaid.net 16.152ms 19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 12.347ms pmtu 1480 19: v3323-mpd.cr1.ewr1.us.occaid.net 88.965ms 20: ge-0-1-0.cr1.iad1.us.occaid.net 93.819ms 21: unknown.occaid.net 100.504ms 22: no reply 23: no reply Suggests 1480, and that's in the cache: [EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache 2001:503:c779:b::d1ad:35b4 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 591sec mtu 1480 advmss 1440 2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0 metric 0 cache mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440 2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 329sec mtu 1480 advmss 1440 So both behave the same apparently in terms of PMTU discovery. I just wondered if it might be an Apache thing because have run into things like SENDFILE optimisation issues before. But you've ruled that out I think. > >$ /usr/sbin/traceroute6 www.ietf.org > >traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from > >2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets > > 1 2001:630:d0:f102::2 (2001:630:d0:f102::2) 1.883 ms 2.719 ms 4.513 ms > > 2 zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1) 4.462 ms 2.485 ms >
Re: www.ietf.org unresponsive over IPv6?
On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote: > Tim Chown wrote: > >Hi, > > > >While I can establish a fast telnet session to port 80: > > > >$ telnet www.ietf.org 80 > >Trying 2001:503:c779:b::d1ad:35b4... > >Connected to www.ietf.org. > >Escape character is '^]'. > > > >Attempting to browse via MSIE leads to timeouts. > > > >Connecting explictly to http://209.173.53.180 to assure IPv4 works fine. > > "telnet -4 www.ietf.org" should do that trick too, but notez bien: > > www.ietf.orgA 209.173.53.180 > www.ietf.orgA 209.173.57.180 > www.ietf.org2001:503:C779:B:0:0:D1AD:35B4 > > We don't know if those are 3 different boxes, or simply 1 box with > multiple links/addresses. As IPv4 traceroutes die off one can't tell > what really is happening behind AT&T (at least from my perspective). > Looking at routeviews it seems that both IPv4 /24's have somewhat > different ASPaths, going over different upstreams. > > >Perhaps some Apache issue or PMTU issue? > > Most likely PMTU. > > >Anyone else experiencing this? > > Works from boxes behind my home DSL line (purgatory.unfix.org) and from > my work box, which is behind SWITCH (2001:620::/32). Tested with telnet, > MSIE and firefox. See below for traces from the DSL. > > Can you try tracepath6, which is available afaik only on Linux boxes > though, to show the MTU path? (iputils-tracepath is the deb package) > > -- > [EMAIL PROTECTED]:~$ tracepath6 www.ietf.org > 1?: [LOCALHOST] pmtu 1480 > 1: 2001:7b8:5:10:74::1 32.572ms > 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 33.623ms > 3: jun1.telecity.ipv6.network.bit.nlasymm 4 34.609ms > 4: zpr2.amt.cw.net asymm 5 35.522ms > 5: so-5-2-0-dcr1.amd.cw.net asymm 6 34.597ms > 6: as0-dcr2.amd.cw.net asymm 7 35.611ms > 7: so-4-0-0-dcr1.tsd.cw.net asymm 8 41.612ms > 8: so-1-0-0-zcr1.lnt.cw.net asymm 9 41.507ms > 9: 2001:7f8:4::31f9:1 asymm 8 137.537ms > 10: v3323-mpd.cr1.ewr1.us.occaid.net asymm 7 141.670ms > 11: ge-0-1-0.cr1.iad1.us.occaid.net asymm 7 146.538ms > 12: unknown.occaid.net asymm 8 152.466ms > > And then no responses, thus most likely filtered for this kind of trace. So I'm on RedHat, have tracepath6 installed (not used before, thanks for the pointer :) and I see in comparison: $ /usr/sbin/tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::21.191ms 2: zaphod.6core.ecs.soton.ac.uk 1. 93ms 3: ford.6core.ecs.soton.ac.uk 1.915ms 4: 2001:630:c1:100::1 2. 66ms 5: 2001:630:c1:10::1 2.353ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 8.440ms 10: po2-0.lond-scr.ja.net 5.273ms 11: po0-0.lond-scr4.ja.net 6.319ms 12: gi0-1.lond-isr4.ja.net 6.238ms 13: 2001:630:0:10::52 8.138ms 14: ge-2-24.r01.londen03.uk.bb.gin.ntt.net11.163ms 15: xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net asymm 16 11.525ms 16: xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net asymm 17 15.225ms 17: 1d-uk6x.ipv6.btexact.com 11.292ms 18: 52.ge0-0.cr2.lhr1.uk.occaid.net 13.643ms 19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 16. 63ms pmtu 1480 19: v3323-mpd.cr1.ewr1.us.occaid.net 88.237ms 20: ge-0-1-0.cr1.iad1.us.occaid.net 92.623ms 21: unknown.occaid.net 101.267ms 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply 31: no reply Too many hops: pmtu 1480 Resume: pmtu 1480 Hmm, 1500 vs 1480. > But traceroute6 works fully: > > traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from > 2001:7b8:20d:0:290:27ff:fe24:c19f, 30 hops max, 24 byte packets > 1 2001:7b8:5:10:74::1 (2001:7b8:5:10:74::1) 13.874 ms 9.645 ms > 10.963 ms > 2 i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl > (2001:7b8:3:31:290:6900:31c6:d81f) 9.943 ms 15.581 ms 14.958 ms > 3 jun1.telecity.ipv6.network.bit.nl (2001:7b8::290:6900:1c6:7c1f) > 16.953 ms * 10.6 ms > 4 zpr2.amt.cw.net (2001:7f8:1::a500:1273:1) 10.972 ms 11.501 ms > 10.99 ms > 5 so-5-2-0-dcr1.amd.cw.net (2001:5000:0:12::1) 11.987 ms 11.614 ms > 11.986 ms > 6 as0-dcr2.amd.cw.net (2001:5000:0:11::2) 11.
www.ietf.org unresponsive over IPv6?
Hi, While I can establish a fast telnet session to port 80: $ telnet www.ietf.org 80 Trying 2001:503:c779:b::d1ad:35b4... Connected to www.ietf.org. Escape character is '^]'. Attempting to browse via MSIE leads to timeouts. Connecting explictly to http://209.173.53.180 to assure IPv4 works fine. Perhaps some Apache issue or PMTU issue? Anyone else experiencing this? We're not seeing issues with any other IPv6 sites/services. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Mon, Jul 17, 2006 at 10:56:08AM -0400, Melinda Shore wrote: > > As the number of meeting groups grow and the meetings become more > densely packed, the jabber transcripts are useful for following > what's going on in a meeting you're not in, as well as providing > feedback. Improving WLAN (802.11a seems popular :) helps jabber scribing. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Mon, Jul 17, 2006 at 11:38:15AM -0400, Stephen Campbell wrote: > > Or skip the car. Fly into LAX, take one of several shuttles to Los > Angeles Union Station, and take Amtrak's "Surfliner" to San Diego. > These trains run every 1 to 2 hours and get to San Diego in less than > 3 hours. And it's hassle-free. Not so good after 9+ hours on a plane though, is it? Nor is driving. Minneapolis has a good selection of direct flights, as does Washington or San Francisco if people want 'nicer' places. Having to hop just adds to the drain of travelling :( -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An Absolutely Fantastic IETF Meeting Network - Redux
On Wed, Jul 12, 2006 at 06:36:45PM -0400, Ed Juskevicius wrote: > >To echo Harald's words from Dallas: > > - Just wanted to state what's obvious to all of us by now: > > - This time the wireless WORKED, and Just Went On Working. > > - THANK YOU! > >In addition, I want to extend my personal compliments to our >Ericsson, Combat Networks and the entire NOC team for a very good job. Yes, it's been very good this time. Of course, sod's law kicked in last night as soon as the wireless was mentioned in the plenary, it seemed to disappear, as if to make us all aware how much we appreciate it :) Also the presence of tables again in the front rows, along with ample power sockets, was very welcome. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wasting address space (was: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric))
On Mon, Jun 05, 2006 at 08:12:28PM +0200, Iljitsch van Beijnum wrote: > > Having to choose between /60 and /48 would be much better than having > to choose between /64 and bigger in general, as it removes the "will > I ever need a second subnet" consideration, the average allocation > size goes down and moving to a /48 after having grown out of a /60 > isn't too painful. There's a certain appeal to this, to have to renumber before your network grows too big. Interesting suggestion. > It's also really helpful if all ISPs use the same subnet sizes. For > instance, I can set up my routes as DHCPv6 prefix delegation clients, > so they can be reconfigured with new address prefixes automatically > when changing ISPs, but I still need to put the subnet bits (and > therefore the subnet size) in the configuration by hand, so having to > change that defeats the purpose of the exercise. Which was the point of /48 pervasively? -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-IPV6 maintenance of one of the www.ietf.org servers - 2006/06/03 - 12:00am EST
On Fri, Jun 02, 2006 at 09:29:21PM -0400, [EMAIL PROTECTED] wrote: > > Hi All, > > Tomorrow Saturday June 3 at 12:00am EST, we will be taking down one of > the round robin www servers for the IETF (209.173.53.180) for > maintenance in preparation for supporting IPV6. The outage should be > less than 1 hour. This system also serves as the primary site for... > > noc.ietf.org > www.iab.org > www.iesg.org > > so those sites will also be down. Congratulations! $ telnet www.ietf.org 80 Trying 2001:503:c779:b::d1ad:35b4... Connected to www.ietf.org. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 66th IETF - Registration and Hotel Accommodations
On Wed, Apr 19, 2006 at 06:07:50PM -0500, Spencer Dawkins wrote: > > Thanks to IAD for opening registration (helps with visa requests, although > this is less of a problem in Canada than "elsewhere in North America"). Yes, very nice to have the hotel and registration open 3 month in advance this time, well done! I called direct, got a booking and a confirmation PDF by email, very easy. But note the hotel is not the meeting venue as far as I can tell. Some info on distances involved (or even a map showing locations) would be helpful. Using zip codes on www.multimap.com (H3C 3Z7 for the hotel and H2Z 1H2 for the Palais) suggests it's a couple of blocks along a fairly major road, which should be easy walking distance... -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On Thu, Mar 30, 2006 at 01:36:18PM +0200, Iljitsch van Beijnum wrote: > > The thing that is good about IPv6 is that once you get yourself a / > 64, you can subdivide it yourself and still have four billion times > the IPv4 address space. (But you'd be giving up the autoconfiguration > advantages.) I noticed that by deafult MS Vista doesn't use autoconf as per 2462, rather it uses a 3041-like random address. See: http://www.microsoft.com/technet/itsolutions/network/evaluate/new_network.mspx "Random Interface IDs for IPv6 Addresses To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Server "Longhorn" and Windows Vista by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses." That reads to me like no 2462 by default. Maybe I'm misinterpreting. One could envisage an option where that randomness is applied to 48 host bits not 64. If you really really wanted to do that. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On Wed, Mar 29, 2006 at 11:04:15PM +0200, Iljitsch van Beijnum wrote: > > What was the problem again? Apparently that Steve Deering is an arrogant, stupid engineer. Allegedly ;) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote: > > Tim Chown wrote: > > If you deploy IPv6 NAT, you may as well stay with IPv4. > > You're the one who convinced me some three years ago that there will be > IPv6 NAT no matter what, what's the message here? I think there will be IPv6 NAT, because some people will want it. That doesn't mean it's rational to deploy it :) > > See also > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt > > Remember: Users don't read drafts/RFCs. And users don't walk into PC World and say 'I'd like a NAT router for my home network please'. They probably ask for a broadband modem, or something that doesn't specify NAT. > > We have deployed IPv6 in our enterprise (throughout). > > Could you have done it if you did not have the > research dollars^H^H^H^H pounds? While we ironed out many issues with research funding assistance in 6NET, I would say the deployment we have now could be done as part of a natural evolutionary procurement process. The 'cost' is real terms is not that high. We have had to invest time in updating OSS-type elements, but much of the rest comes 'out of the box'. I guess we would have had some training costs as a 'normal' enterprise, but we've helped address that in the academic community by running hands-on IPv6 workshops (just as the Internet2 people do for their community). > Phillip, there a few (such as: NAT typically requires hard state, which > is a pain to replicate if there is more than one edge router). NAT is > not completely evil, but it's far from being clean. Pretending that > there are no good reasons against NAT is going to achieve the same as > trying to eliminate it: nothing. I note Phillip's extremes of view on IPv6 and DNSSEC. It's interesting to compare how critical these two elements are, and his views on them. > Yes, and since site-locals have been deprecated they will also hijack an > unallocated block of addresses to use as private, same what happened > prior to RFC 1597 for the very same reasons (difficult/pricey to get > PI). There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt. > When people will begin to scream bloody murder to use the extended bits > (because v4 is getting near exhaustion) the infrastructure could be > already in place, and then the pressure will be on software developers > to recode their stuff with 128-bit addresses. When that has happened, > then we can make use of all these reserved fields for better purposes, > and possibly allocate PI to everybody which is another pre-requisite to > get rid of NAT. And there's always IPv8 ;) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Interesting discussion. Keith is hitting all the nails on the head. Phillip seems to suggest that consumers buy NATs out of choice. They don't have any choice. I surveyed my final years students last month. Just four have a static IPv4 allocation for their home network, and only one has more than a /32 for use internally. ISPs just don't give you a choice (unless you are prepared to pay a non-negligible fee). If you deply IPv6 NAT, you may as well stay with IPv4. The first ISPs offering IPv6 are offering /48's here. The allocations to FT etc (they have a /19) are clearly made on the basis of end site /48's. See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt We have deployed IPv6 in our enterprise (throughout). We're seeing some early benefits from (student) driven new services. Students are also using transition mechanisms to enable simpler use of applications between homes (rather than battling a NAT out and a NAT in on communication paths). No regrets from deploying, no significant issues either for the existing IPv4 service. And there's more than just address space to take advantage of, like embedded RP for multicast applications. Tim On Tue, Mar 28, 2006 at 12:48:13AM -0500, Keith Moore wrote: > >In this case the benefit to running NAT on my home network is that it saves > >me $50 per month in ISP fees, means I have wireless service to the whole > >house and means that guests can easily connect. > > one immediate benefit to my running IPv6 on my home network is that I > can access any of my machines from anywhere else on the network (via > 6to4), as long as I'm not behind a NAT. my home network also has a v4 > NAT, so it's not as if they're mutually exclusive. > > >I have never seen a coherent, rational argument as to why the network > >numbering on my internal network should be the same as the network > >numbering > >on the Internet. > > obviously you've never tried to write a distributed application in a > NATted network. and presumably you never tried to do anything with UUCP > mail (which had naming conflicts) or a large DECnet (which had address > conflicts). the problems are immediately obvious to those of us who > have had to deal with those disasters. > > in brief: one reason is so that apps can have the same view of the > network regardless of whether they're hosted on your internal network, > or on an external network, or on a combination of the two. it's MUCH > simpler if apps don't have to worry about the fact that host A has > address A1 from network X and address A2 from network Y. particularly > since in a network with scoped addresses, hosts don't really have any > way of knowing which network they're on. > > there are other reasons also: routing, coherent network management, DNS > consistency. a network with scoped addressing is like a city where all > of the streets have the same name. it becomes pretty difficult to navigate. > > >People will still want to do NAT on IPv6. > > true. people do all kinds of evil things that break the net. our > protocols will only work to the extent that people follow the > specifications. when people start breaking things, the protocols and > applications start failing. NAT is a good example. > > in ipv6, we can provide better ways of solving the problems that people > think they're solving with NATs. if we fail to do that, or if people > insist on using NATs anyway, we're screwed. but that's not a reason to > give up without trying. > > either do something to help or get out of the way. > > Keith > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed 2008 - 2010 IETF Meeting dates
On Mon, Mar 27, 2006 at 10:38:03AM +0200, Brian E Carpenter wrote: > > I don't think the analogy holds, for a number of reasons. (As a matter > of interest, there were about 6 participants out of 350 with addresses > in Europe at the March 1991 IETF meeting, and about 19 out of 530 > in March 1993. At that point, scheduling against RIPE would certainly > have become a practical problem.) You have to consider the most important clashes; IETF66 clashes with the World Cup Final on July 9th. I hope Canada has good coverage, if not a good football team :) Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from "hosts" to "sponsors"
On Sat, Mar 25, 2006 at 12:43:57PM -0500, Henning Schulzrinne wrote: > >Indeed. Not only is it small, it isn't where corporate bean counters > >put their attention, which is air fare, hotel, and per diem. > > Brian, > > this is not universally true. With cheaper air fares and not staying > in the overpriced Hilton hotel rooms, my IETF65 meeting fee was > almost exactly the same as my combined hotel and air fare costs. For > those of us not on corporate expense accounts, it's the total amount > that matters. Being trapped away from the IETF hotel for one night by the flood, the quality of a nearish (5-10 min drive, probably 1h walk) motel was a little of an eye opener, very similar quality for $69+taxes, and a bigger bathroom. Why the Hilton creates such enormous rooms with such small en-suites is a mystery to me :) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Jabber chats (was: 2 hour meetings)
On Fri, Mar 24, 2006 at 12:10:47PM -0500, Scott Leibrand wrote: > On 03/24/06 at 5:00pm -, Stig Venaas <[EMAIL PROTECTED]> wrote: > > > Personally I find jabber (and similar technologies) much more convenient > > than voice. I've used that a few times with a small group of people to > > discuss and solve technical problems. I feel it allows more interactive > > discussions and is also easier non-native English speakers, > > > > I think using the wg jabber rooms we got for regular discussions of > > specific issues is a great idea. > > I would wholeheartedly agree with this sentiment. And in my mind, that > brings up a related question: > > Can anyone affirmatively state whether rooms.jabber.ietf.org will remain > up between meetings? If the plan is to take it down, I would lobby for > re-consideration... I believe they are, as logs from the rooms are on the web site (or were last time I looked :) So you get auto archives. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Jabber chats (was: 2 hour meetings)
On Fri, Mar 24, 2006 at 08:49:28AM -0800, Hallam-Baker, Phillip wrote: > > You mean like holding a bi-weekly teleconference? > > VOIP is getting to the point where this is practical. Well yes, telecons are fine for design team work, but for an open interim meeting you need to determine which systems will work for maybe 50 virtual attendees and not devolve to chaos :) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Jabber chats (was: 2 hour meetings)
On Fri, Mar 24, 2006 at 07:49:46AM -0800, Michael Thomas wrote: > > Maybe there's an intermediate between email and full f2f time? > Something like having well known jabber chats to simulate the > quickness of f2f conversation without having to be there? There > is some amount of precedence for this with the IESG's telechats. > They could be structured like regular wg meetings with moderation, > etc for well known ones, and the same room could be reused for > ad hoc/sidebar discussions when not in use. Well, if we make remote participation too good, we may end up with rather empty meeting rooms and a bankrupt IETF ;) What we should do, given the rush of work that happens pre-ID cutoff, is maybe look at such technology for interim meetings, and have the IETF support some infrastructure to help interim meetings run more effectively, maybe even without a physical meeting venue. Some WGs might then run more interim virtual meetings and help distribute the workload over the year more smoothly. -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
On Thu, Mar 23, 2006 at 11:48:19PM -0600, JORDI PALET MARTINEZ wrote: > > The results is also better for all (even participants), because the > logistics and local-planning is done more coherently. I think there's some unfair handwaving in this thread. One option however would be to seek 'partnerships' between vendors and the IETF that span more than one meeting. Unless that impacted the perceived 'neutrality' of the IETF and its standardisation processes. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
On Thu, Mar 23, 2006 at 11:35:13PM -0600, Ken Raeburn wrote: > On Mar 23, 2006, at 21:58, Harald Alvestrand wrote: > >Just wanted to state what's obvious to all of us by now: > > > >This time the wireless WORKED, and Just Went On Working. > > > >That hasn't happened for a while. THANK YOU! > > Mmm... well, my laptop (Mac Powerbook) fell off the b/g network > several times, mostly during plenary sessions, but the problems were > brief, and I usually had no trouble getting back on. It wasn't > perfect, but very much improved over previous meetings. Same symptoms here, in the 'distant' rooms (Cortez et al) when the rooms were full my Powerbook would lose association frequently, but always rejoin when I forced it manually. I'd love to know what was causing that; I've never seen similar symptoms before. My ssh sessions would survive the drops though :) I don't know whether I was using b or g. Maybe a Mac thing? -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nokia 770?
Hi, Is there any way a non-US citizen can buy one of the promotional 770's available at the event and walk out with a receipt in their name? -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
