Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
On 17 jul 2008, at 23.33, IETF Chair wrote: The IESG is considering an experiment for IETF 73 in Minneapolis, and we would like community comments before we proceed. Face-to-face meeting time is very precious, especially with about 120 IETF WGs competing for meeting slots. Several WGs are not able to get as much meeting time as they need to progress their work. As an experiment, we are considering adding two Friday afternoon one-hour meeting slots. The proposed Friday schedule would be: 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II Please share your thoughts about this proposed experiment. The proposed experiment will be discussed on the IETF Didcussion mail list (ietf@ietf.org). so while I sympathize with the need for this, and won't argue against it. I do want to point out that it means that overseas travelers will be 'stuck' for another day (depending on where in the world we are, you can normally make an afternoon overseas flight, but not if we have an afternoon slot). So in order for you to get enough data - I would strongly urge you to also have an afternoon slot in a non-north american meeting location and only afterwards analyze the data. Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 8 jul 2008, at 20.41, Keith Moore wrote: 1) I do understand where the current "last 64 bits are EUId" comes from. 2) Someone (I think it was Keith Moore) said that if the scheme doesn't work for servers AND hosts (i.e no difference) it's a bad scheme. I sort of agree with that, but the reason it doesn't work for servers is simply lack of management tools, and the fact that a lot of protocols / implementations tend to use addresses rather than names. I disagree that it doesn't work for servers. (Or it would be better to say that I'd like to know why you think it doesn't work for servers.) Well, when I change that broken NIC in my server, it will receive a new address that needs to be reflected in the DNS. Sure, that can be automated or updated, but in general you want some stability in the server address. I have actually run my personal mail-server on an EUI-64 address for quite some time. The problem when the NIC failed was that it took until the cache expiry for some servers to contact it again. Like ietf.org. There are other addresses, like router interfaces where EUI64 addresses are simply a nightmare, as when you are doing network troubleshooting you need to keep 128 bits in HEX in memory - which I am too stupid to be able to...an alternative would be to have routing tables do DNS lookups for NEXT_HOPS - it's just a lot of DNS lookups Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
(Apologies for the late reply) On 4 jul 2008, at 15.10, John C Klensin wrote: --On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist <[EMAIL PROTECTED]> wrote: On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Despite the ":-)", I think there is an important question here. Does it imply that this is a use case from which we should be learning... and then fixing the RFCs? Or that you believe that the RFCs are correct and Jeroen's analysis is incorrect? I hope it doesn't mean "the RFCs ought to govern, even when reality and experience seem to contradict them". So, from my POV there are a few issues here. 1) I do understand where the current "last 64 bits are EUId" comes from. 2) Someone (I think it was Keith Moore) said that if the scheme doesn't work for servers AND hosts (i.e no difference) it's a bad scheme. I sort of agree with that, but the reason it doesn't work for servers is simply lack of management tools, and the fact that a lot of protocols / implementations tend to use addresses rather than names. 2) In operational reality, I have learnt that EUI64 for workstations and similar hosts in combination with non EUI64 numbers for servers works quite well and is how I work with deployments. And I have a lot of respect for operational experience and reality. So yes, I think this is worth considering. Do I believe such a rule can be written clearly and get IETF consensusthat is a different question. Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 14 mar 2008, at 13.01, Jari Arkko wrote: > We should also implement future IPv6 experiments and network > deployments. > > But why I'm really sending this e-mail is to suggest that IPv6 might > not > be the only topic for such future efforts. Here's a challenge for the > RAI folks: What about SIP, as in every plenary participant making SIP > calls to each other. Doable? > > Challenge for our IT folks: Internationalized Internet Drafts, > including > file names. Doable? > > ietf.pana in addition to ietf.1x. Doable? I would like to second Jari's statement. To follow up to Joel's comment at the technical plenary on the issue of lack of operators - I believe that if the designers and vendors of some of the IETF standards better understood how they actually worked in real use cases and tried to deployment - we might find a lot more deployment issues earlier. I am all for it. - kurtis - ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
On 29 nov 2007, at 05.55, Pekka Savola wrote: On Wed, 28 Nov 2007, Lars Eggert wrote: I might not be fully up-to-date on our sponsoring process, but as I understand it, a meeting sponsor pays for a fraction of the direct costs for a given meeting. Other organizations charge a sponsor a flat amount that is based on costs that are averaged over multiple meetings. Yes, that means that sponsors of meetings in cheaper locations subsidize meetings in more expensive ones, but it also makes it financially irrelevant to the sponsor which exact meeting they support. By the way, is there another mailing list for us to move this discussion to? Does the IAOC have an open list? You can follow IAOC activity from the minutes at http://iaoc.ietf.org/minutes/iaoc_minutes.html Ooops, the latest minutes posted are from March 1st. I forgot to reply to this before, so here is a catch up reply. We are aware that we are behind on publishing the minutes. There are reasons for that, but the good news is that a batch of minutes are in the process of being approved by the IAOC and should be published shortly. This again gives me the opportunity to solicit for volunteers to acts as scribes for the IAOC - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The code sprint
I just wanted to clarify one of the points on my Wed plenary slides. The Code Sprint was organised by the IETF tools-team , and credit for getting that organised and successful should go to the tools-team and Bill and Henrik! I don't think we can enough appreciate the work that goes into the tools! The Code Sprint on the slides was referring to the ongoing work of rewriting and fixing the security problems that we revealed at the plenary in Chicago. Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Vancouver meeting fees
The community was told at the IETF 69 Wednesday Evening Plenary Session to expect a meeting fee increase for IETF 70 in Vancouver. The purpose of this message it to advise you of the amount of the increase and provide the reasons for the increase. We are into September, which means two-thirds of 2007 is now behind us. We know what our IETF expenses have been year-to-date, and we can project our expenses for the rest of 2007. We also know that our meeting revenue for the first two meetings have been below expectation as a result of attendance averaging one hundred fewer attendees per meeting than anticipated. With this information, we can see that the operations will incur a shortfall of more than $200K if we do not take actions for the Vancouver meeting. Accordingly, the IAOC will increase the IETF meeting fee for the Vancouver meeting by $100. By taking this action, our deficit for all of 2007 should be reduced by almost half. To address the remaining deficit, we will continue to work with the Internet Society staff in their efforts to attract additional host and sponsorship support for the Vancouver meeting and to reduce expenses wherever possible without impacting the meeting and experience of the attendees. To date, we have received generous contributions from Microsoft and Telus, which are appreciated, but are not enough to make Vancouver a fully hosted meeting. With respect to what happens in 2008, please note that the IAOC has not made any decisions yet about meeting fees for next year, but we will be actively evaluating the cost of delivering essential services, looking at new approaches to raise additional revenue, and taking another look at future meeting locations with the goal of increasing meeting attendance. More financial information is available at: http://iaoc.ietf.org/ budget.html. In particular see Budget Overview and Year End Forecast. As a final point of information, please be advised that registration for the Vancouver meeting will begin this week. Kurtis Lindqvist IAOC Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAOC office hours
The IAOC will again be holding open office hours in Parlor A on Wednesday 16.00-17.00 Thursday 16.00-17.00 On behalf of the IAOC - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAOC Scribes
All, The IAOC minutes are posted, whenever available, at http:// iaoc.ietf.org/minutes.html. Since the days of the IASA transition team, Marshall Eubanks has acted alone as the scribe for the IAOC. On behalf of the IAOC I would like to take this opportunity to thank Marshall for the extraordinary work he has done and the dedication he has showed since the IASA-TT days! In order to off-load Marshall the IAOC now would like to recruit a second scribe for it's meetings. Volunteers should write to [EMAIL PROTECTED] by July 20th. We'll keep names confidential, unless people choose to volunteer in public. The general guidelines are: - at least one scribe attends the regular IAOC and IETF Trust telechats (10:00-11:00 US ET on 1st and 3rd Thursdays of the month). - the scribe(s) will record narrative minutes of the discussions, but they will not take part in the discussions except to ask for clarifications. - Minutes are expected to be approved by the IAOC at the next scheduled meeting. - kurtis - IAOC chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
On 6 nov 2006, at 22.05, Patrik Fältström wrote:
On 17 okt 2006, at 09.33, John C Klensin wrote:
Of course, as suggested in earlier notes, I'd find the idea of
endorsements ("supporters") completely acceptable and even a
good idea (i) if anyone in who participates actively in the IETF
could do an endorsement, (ii) if there were no restriction on
repeat endorsements, (iii) if the endorsements were expected to
contain analysis and information that actually contributed to
the consideration of the appeal, and (iv) if the whole
endorsement idea had been sufficient thought through that we
could have confidence that requests for endorsements did not set
off discussions firestorms on the IETF list.
The reason why I like the "number of people endorsing the appeal
must be greater than N" is because that is for me a simple
objective rule that forces the (individual) person that appeals
first talk with others, and agree with others on the content of the
appeal itself.
So, I support the suggestion from Olaf.
I would just like to voice that I agree with Patrik and supports
Olaf's draft as well!
- kurtis -
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: LA -> San Diego transportation (Was: Re: Meetings in other regions)
I did this the last time we where in San Diego. The only thing to be concerned about is at least United operated small planes with not to good frequency (at least then) and tends to fill up on Saturday afternoon and Sunday morning (I noticed). Then going from International to domestic at LAX turned out to be a small adventure but I think that was a unique experience I would be happy to tell in a bar..:) - kurtis - On 19 jul 2006, at 00.29, Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX -> SAN as his last leg. On 7/18/06, Doug Barton <[EMAIL PROTECTED]> wrote: [ Disclaimer, I grew up in San Diego and now live in the LA area, so I have biases in both directions. :) ] [EMAIL PROTECTED] wrote: > (BTW, how much would a taxi from LAX to San Diego cost? And would > you expect taxis willing to do it?) It's 120+ miles from LAX to the Sheraton San Diego, so a taxi isn't practical. However, there are various ground transportation services that ply that route, so if there is sufficient interest I wouldn't mind looking into it and posting the results. I would say that the suggestion already offered of the train from LA's Union Station to San Diego is a good one. The city of Los Angeles recently introduced a low cost shuttle between the station and the airport, and the train station in San Diego is just a few miles away from the Sheraton. My mother takes the train up from San Diego when she comes to visit her granddaughter (I am of course a second consideration), and has very good things to say about it. The train spends a good deal of its time within view of the coast, so you get a fairly scenic ride as well. All that said, they do have commuter flights between LAX and SAN, so a connecting flight is not as absurd as it sounds. hth, Doug -- If you're never wrong, you're not trying hard enough ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 18.00, Hallam-Baker, Phillip wrote: From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... Precisely. Just what is this fetish about keeping the IP address the same as the packet travels? I will have to get better at making irony clearerI most certainly hope we are not heading down the route I suggest above. I am _afraid_ we are though. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 13.46, Keith Moore wrote: NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... the overlay networks depend on having some hosts that aren't behind a NAT to serve as tunnel endpoints for hosts that do. this will become less viable in the future as IPv4 address space gets more and more scarce. also, for the most part, overlay networks do not perform as well as native networks (there are exceptions, as in bittorrent). so they do not abstract (all of) the shortcomings away. They don't, but they do give the users back some of the benefit's they lost from being behind the NAT. However, that is now transpartent to the user. "Uh, I can't buy this VoIP service for some technical reason, but this cool Skype stuff just works...". The problem is that for the users to get away from the NAT swap, they will need to go down the operators "value-added-services-path". OTOH, one transition path away from NATs might be to extend NATs so that they support creation of overlay networks. such devices could also aid v4/v6 coexistence. I think you will see v4+NAT && overlaynetworks && IPv6-for end to services the providers want to sell (see IPTV and VoIP). Note, that this is end-to-end INSIDE the providers network. There is no incentive (yet) for providers to allow end-to-end on the Internet. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 00.11, Keith Moore wrote: NAT is a done deal. It's well supported at network edges. It solves the addressing issue, which was what the market wanted. It voted for NAT with dollars and time. It is the long term solution - not because it is better, but because it is. NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
On 5 mar 2006, at 11.11, Peter Dambier wrote: Kurt Erik Lindqvist wrote: On 3 mar 2006, at 18.15, Joe Baptista wrote: Kurt Erik Lindqvist wrote: To best of my knowledge, that there are no new Chinese root- servers - despite what the press says. And at least we have not seen a drop in queries to our anycast instance in Beijing yet so there even seems to be data to support that... There are. Check Peter Dambiers messages for details. Exactly what does he prove there? Please explain Take this one [...] So by analogy this ; <<>> DiG 9.2.2 <<>> @mariehamn.kurtis.pp.se kurtis.fi any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32651 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 6 ;; QUESTION SECTION: ;kurtis.fi. IN ANY ;; ANSWER SECTION: kurtis.fi. 86400 IN SOA mariehamn.kurtis.pp.se. hostmaster.kurtis.pp.se. 2006030201 28800 7200 604800 86400 kurtis.fi. 86400 IN NS vovve.besserwisser.org. kurtis.fi. 86400 IN NS casper.besserwisser.org. kurtis.fi. 86400 IN NS tankgirl.kurtis.pp.se. kurtis.fi. 86400 IN NS mariehamn.kurtis.pp.se. kurtis.fi. 86400 IN MX 50 mariehamn.kurtis.pp.se. kurtis.fi. 86400 IN MX 100 casper.besserwisser.org. kurtis.fi. 86400 IN MX 10 lemland.kurtis.pp.se. proves there is an alternative .fi registry then? Sigh.. Maybe the root has changed and you are on the wrong server. What is the right and what is the wrong server? Tiscali have updated their nameservers to be able to cope with those emails. Good for them! Maybe anycast has played a trick on you and you cannot see the right nameservers :) Oh please...anycast have nothing to do with content. I think that you are pretty mixed up with what a root-server is and what an authoritative server is. But again, that is just me. I will now go back into lurk mode on this list... - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
On 3 mar 2006, at 18.15, Joe Baptista wrote: Kurt Erik Lindqvist wrote: To best of my knowledge, that there are no new Chinese root- servers - despite what the press says. And at least we have not seen a drop in queries to our anycast instance in Beijing yet so there even seems to be data to support that... There are. Check Peter Dambiers messages for details. Exactly what does he prove there? Please explain Second - you will notice an increase in what you guys at the roots call I think illegal or erroneous TLDs - which see http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/ I see no increase in these, but we do see a lot of them in general... Incidentally - since my article was written I have not seen any further studies concerning root traffic from CAIDA or anyone else. In fact root operators don't really share much with the world - do they? Of query data? No and this a complex issue, at least for us that involves local laws regarding privacy and personal integrity. As for qps data, sharing that in real-time is at least by us considered a security issue. That said, we will as of the end of this quarter start publishing a quarterly newsletter that among other things will include some data over the past quarter. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
On 3 mar 2006, at 17.58, Peter Dambier wrote: To best of my knowledge, that there are no new Chinese root- servers - despite what the press says. And at least we have not seen a drop in queries to our anycast instance in Beijing yet so there even seems to be data to support that... But what do I know... - kurtis - Hi Curtis, at least we can see these domains. Can you see them too, on the nameservers you are using? ; <<>> DiG 9.1.3 <<>> -t any XN--55QX5D. @hawk2.cnnic.net.cn. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46417 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;XN--55QX5D.IN ANY ;; ANSWER SECTION: XN--55QX5D. 3600IN SOA hawk2.cnnic.net.cn. root.cnnic.cn. \ 2006030104 3600 900 604800 3600 XN--55QX5D. 3600IN NS hawk2.cnnic.net.cn. XN--55QX5D. 3600IN NS cdns3.cnnic.net.cn. XN--55QX5D. 3600IN NS cdns4.cnnic.net.cn. XN--55QX5D. 3600IN NS cdns5.cnnic.net.cn. ;; ADDITIONAL SECTION: cdns3.cnnic.net.cn. 38 IN A 210.52.214.86 cdns4.cnnic.net.cn. 518 IN A 61.145.114.120 cdns5.cnnic.net.cn. 518 IN A 61.139.76.55 ;; Query time: 410 msec ;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.) ;; WHEN: Fri Mar 3 17:53:18 2006 ;; MSG SIZE rcvd: 215 Which does not show that there is a new root-server in China...it merly shows that you have found a server inside china that happens to have a IDN TLD configured. This would be analogue to the testbed that NIC-SE (Swedish registry) was running for DNSSEC until they put this into their production system. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
On 2 mar 2006, at 09.26, Mohsen BANAN wrote: More than 5 years ago I predicted what the Chinese government announced today. What happened today: http://english.people.com.cn/200602/28/eng20060228_246712.html http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET- POLICY-MII-DOMAIN%20NAME-DNS http://www.domainesinfo.fr/vie_extensions.php?vde_id=859 http://politics.slashdot.org/politics/06/02/28/1610242.shtml http://news.com.com/China+creates+own+Internet+domains/ 2100-1028_3-6044629.html was obvious and quite easy to foresee. Addressing the requirements of a very real international multi-root environment is also not all that hard and will likely naturally evolve. To best of my knowledge, that there are no new Chinese root-servers - despite what the press says. And at least we have not seen a drop in queries to our anycast instance in Beijing yet so there even seems to be data to support that... But what do I know... - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: a new DNS root for the world?
On 6 okt 2005, at 10.00, JFC (Jefsey) Morfin wrote: We now have 1.5 billions (most of the Internet users and many more) who will access the NewStar root file. As Spencer pointed out - you won't. .gprs is for the infrastructure that the users are connected to. Besides that walled-gardens will leak and are not a good thing (tm). - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Administrative Director Job Announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Internet Engineering Task Force (IETF) is responsible for developing and defining the standards and protocols that make up the Internet. The IETF was established in 1986, and has since then been the center of development for the technologies that make up what we think of as the Internet. Until now, administration of the IETF has been carried out by helper organizations; the IETF has had no direct staff that was working only for the IETF and its interests. The community that makes up the IETF has as part of a long-term administrative restructuring, decided to create an Administrative Support Activity, the Internet Administrative Support Activity (IASA). The IASA will formally be structured as a function of the Internet Society (ISOC). To run this activity, the IASA Transition Team is now seeking a highly capable individual to serve as IASA Administrative Director (IAD). The IAD will lead the work of supporting the organization that defines and develops the future Internet and associated technologies. As IAD, you will be reporting to the IETF Administrative Oversight Committee (IAOC) and be accountable to the IETF community. This is a highly visible and very demanding job; you will be expected to work daily with some of the leading Internet technologists of the world. You will be expected to: o Document the administrative requirements of the IETF, IESG, IAB and IRTF, and manage the work to fulfill them. o Establish the IASA annual budget, oversee financial administration, and report on IASA work to the IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Negotiate contracts with service providers and establish procedures for measuring and reporting the performance of these providers. o Serve as the day-to-day responsible person for administrative operations that support the IETF process, managing a number of contractors and working with a number of volunteers. o Serve as the primary staff resource for the IASA. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people from numerous countries. This requires a large work capacity, the ability to handle many simultaneous tasks, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. One goal of IASA is to achieve as much transparency and accountability as possible, so good communication skills and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million per year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to get up to speed quickly and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The person hired will be an employee of the Internet Society (ISOC). The Internet Society is based in Reston, Virginia and in Geneva, Switzerland, and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter or use the Internet Society facilities. In either case, you should be prepared to travel frequently to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be fluent in spoken and written English. Applications should have a covering letter and include a CV. They can either be sent to [EMAIL PROTECTED], or an applicant can fill in the application form at htt
Re: End of issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-01-14, at 11.50, Brian E Carpenter wrote: > John C Klensin wrote: > >> ... but I note that we are still turning over rocks from >> which new issues crawl. > > And the first year of operation will certainly reveal > other issues, which may move faster than a crawl. > > I am deeply convinced we will be revising this BCP after > a year's experience. So I think we will very soon have to > agree to leave some known issues open. > > (fyi, the average lifetime of the first two versions of > the IETF standards process and of the Nomcom procedures > was 24 months... it seems to take us a couple of iterations > and ~4 years to get a process BCP right.) I would like to voice support for Brian's statement. I think that we need to realise that we can't foresee all issues and our anticipation's of them are best guesses. There is nothing like real-life experience and at some point we need start getting that instead of arguing. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQefksaarNKXTPFCVEQIGHwCg3ubaU2mF7r+1z8evNZ0PUiiP+PoAnA2p raE6Pf0VPgCk9i38WUebmTX4 =Jx0a -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Updated version of the IAD announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Please find below an updated version of the IAD job announcement. This is based on the feedback we received here on the list, as well as on feedback received from a professional. The comment period this time will be until Sunday evening and we expect to post this on Monday. - - kurtis - - The Internet Engineering Task Force (IETF) is responsible for developing and defining the standards and protocols that make up the Internet. The IETF was established in 1986, and has since then been the center of development for the technologies that make up what we think of as the Internet. Until now, administration of the IETF has been carried out by helper organizations; the IETF has had no staff of it's own that was working only for the IETF and it's interests. The community that makes up the IETF has decided to move into a more formal operating model, and as part of this move, it has created an Administrative Support Activity. To run this activity, the IETF Administrative Support Activity (IASA) Transition Team is now seeking a highly capable individual to serve as IASA Administrative Director (IAD). The IAD will lead the work of supporting the organisation that defines and develops the future Internet and associcated technologies. In the role as IAD, you will be reporting to the IETF Administrative Oversight Committee (IAOC) and be accountable to the IETF community. This is a highly visible and very demanding job; you will be expected to work on a daily basis with some of the leading Internet technologists of the world. You will be expected to: o Document the administrative requirements of the IETF, IESG, IAB and IRTF, and manage the work to fulfil them. oEstablish the IASA annual budgets, oversee their financial administration, and report on IASA work to the IETF. oWork with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. oNegotiate contracts with service providers and establish procedures for measuring and reporting the performance of these providers. oServe as the day-to-day responsible person for administrative operations that support the IETF process, managing a number of contractors and working with a number of volunteers. o Serve as the primary staff resource for the IASA. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: oThis job is public service. You should be able to work successfully with large numbers of people from numerous countries. This requires a large work capacity, the ability to handle many simultaneous tasks, and the ability to listen carefully. oThis is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. One goal of IASA is to achieve as much transparency and accountability as possible, so good communication skills and previous similar experiences are valued. oThis job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The person hired will be an employee of the Internet Society (ISOC). The Internet Society is based in Reston, Virginia and in Geneva, Switzerland, and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter or use the Internet Society facilities. In either case, you should be prepared to travel frequently to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be flue
Draft version of the IAD job announcement from the IASA TT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please find below the draft call for applications for the IAD position. The current timeline for moving forward is as follows DEC 18 Send out call for applications to o IETF-Announce list o ISOC announcement lists o NANOG, SANOG, NORDNOG, AFNOG, etc o Ask RIRs to forward to their respective announcement lists JAN 15 evaluation of applicants start We would appreciate any feedback as soon as possible, either on the [EMAIL PROTECTED] list OR directly to the IASA team at [EMAIL PROTECTED] On behalf of the IASA-TT - - kurtis - The IETF Administrative Entity is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable to the IETF community. This is a highly visible and very demanding job. You will be expected to: o Working with the IAOC to document and cater for the administrative requirements of the IETF, IESG, IAB and IRTF. o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish procedures for meassuring the performance of these providers. o Eventual mangagement of support staff and contractors. o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. o Work with our liaison organizations, such as the RFC Editor and the IANA. o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The Internet Society is based in Reston, Virginia and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be fluent in spoken and written english. Applicants should forward a resume, references, and any other relevant materials, with a cover letter explaining why they feel they are the right person for this position written in text or PDF, in an email sent to [EMAIL PROTECTED] Applications will be evaluated starting January 15th. The evaluation of applications, selection and appointment of the IAD will be made by the IASA transition team. The list of applicants will not be posted publicly, but will be reviewed in confidence by members of the evaluation committee, the IAB, and the IESG. -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQcFS8aarNKXTPFCVEQKk/wCgykkbRICv/w4TbgaRTa+iKeeDImkAn0S4 hcLPkCUqazD9N7nzjRshjLkf =QR57 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.iet
Re: BCP-02: Financial statements and Audits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-12-13, at 08.41, Bernard Aboba wrote: > Margaret Wasserman wrote: > > "ISOC's finances are already audited by an independent auditing firm > on a > yearly basis." > > Yes -- but the yearly audit typically isn't focused on validating > whether > the restrictions described in this BCP are being carried out. If > you're > looking to certify the validity of the divisional accounting and the > BCP > restrictions, that would require additional work by the auditor. > > Kurt Erik Lindquist said: > > "Also, if you will need an audit, I don't expect you/us to want ISOC to > conduct it." > > The ISOC yearly audit is conducted by an independent auditing firm, > not by ISOC. Yes. I think I meant the same as above. However that can be part of the ISOC audit, or not. I think that is up to IAOC to decide as they would be receiving the audit. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQb16jqarNKXTPFCVEQIVUgCghKJHOXJz5imvdyg2jiIHpUd6AE0AoPBu w3N+3ZE/JeD7/7eHWzcpt5Vl =eBgu -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: BCP-02: Financial statements and Audits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-12-09, at 16.58, Bernard Aboba wrote: > Section 5.1 > > "For bookkeeping purposes, funds managed by IASA should be accounted > for > in a separate set of accounts which can be rolled-up periodically to > the > equivalent of a balance sheet and a profit and loss statement for IASA > alone after taking into account the effect of common items paid for or > received by ISOC as a whole." > > I think we want to specify what financial statements are produced in > more > detail, and how an audit may be triggered. > > Suggest this be changed to: > > "For accounting purposes, funds managed by IASA should be accounted > for in > a separate set of accounts, in order to allow the general of separate > financial statements for IASA, after taking into account the > allocation of > common items paid for or received by ISOC. The allocation of these > common > items shall be agreed upon between the ISOC and the IAOC as part of the > budget process. > > Financial statements to be produced for IASA include (but are not > limited > to) an Income (Profit/Loss) Statement, Balance Sheet and Statement of > Cash > Flows, in accordance with Generally Accepted Accounting Pinciples > (GAAP). > Should the IAOC not be satisified with these financial statements, the > IAOC shall have the right to request that the ISOC conduct an audit." I kind of like this proposal, but this second paragraph is something that I think is up to IAOC to agree with ISOC on. Also, if you will need an audit, I don't expect you/us to want ISOC to conduct it. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQbnQVqarNKXTPFCVEQLlEwCfUpf4eY8UbKp+ViKH8E3AjzwFCboAoN2h cImKVq0/Fes9tE6EgKMvC9jB =V9Kr -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: BCP-02: Requirements for Outsourced Activities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-12-09, at 17.02, Bernard Aboba wrote: > Suggest this be rewritten to: > > "The IAOC is accountable for the structure of the IASA and thus decides > which functions are to be outsourced. All outsourcing must be via > well-defined contracts or equivalent instruments. Both outsourced and > in-house functions must be clearly specified and documented with > well-defined deliverables, service level agreements, and transparent > accounting for the cost of such functions." I think this is overkill. It is up to the IAD/IAOC to decide how to account for costs of outsourced contracts, so I would put a period after "service level agreements". - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQbnQ86arNKXTPFCVEQIuVgCg7PnKM/QvQmKnc0juGx4Twox4y6UAn3NQ t1DeWBqrp/c3bBRNvWQG06Fm =WA3w -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-20, at 05.13, JFC (Jefsey) Morfin wrote: > This does not mean that you are bound to a single number, the same you > are not bound to a single mobile. Let not think "the users should do > it the way I think", but "I am to permit the users to do it the way I > never thought they would do it", because it is generally the way these > people behave > > Does this respond your remark? No, I made a poor attempt at being sarcastic. John seems to have gotten my point and explained it well. > Everyone agrees that we need more addresses; so everything seems fine. > Except that it does not catch. Why ? I think Brian is right when he says we don't know this yet. > I think it does not catch, because this is the old IPv4 model, that it > still relies on ISPs and that if addresses are longer they still are > far too short. Because they are managed by RIRs who have no societal > and no political power. But mainly because we consider the wrong > product: no one is interested in the Version 6 of the IP protocol. > There are a lot of people interested in the management and political > capacity to manage /128 long addresses. > > The real product is the addressing plan. And the reasons why no one is > excited are that: > > - these addresses are managed "a la IPv4", as a unique Vint > Cerf's/ICANN numbering area. This is what they want to correct with > ITU. I submit there is no conflict. IPv6 has 6 different numbering > plans. Let say that 001 is for the US Vint's legacy and 011 for > international. That Vint can manage the 001 area and the ITU the 011 > area. This is status quo. Actually not. Currently there is (at least in perception) a global addressing policy. This means that a change in policy that would affect the organizations carrying the burden of the changes (providers) is transparent to them, and they and anyone else can influence it. In your world this does not hold so it's not status quo. > - now, the way ITU wants to manage the international digital address > numbering plan is in using DCC (or the like). (DCC is data country > code). The same as there are ccTLDs in naming. So Frank has no problem > for his SOPAC islands. They are entitled as many addresses as others. > Does that change anything for the RIRs and the routing? No, this is > simple address management. The problem with the SOPAC islands is artificial and AFAIK in the process of being solved. The DCC plan is naive at best, and already implemented in several countries by he use of NIRs. So if a country feels this is a real need, it is already done in the current system. > - the way the countries will manage their numbering space is up to > them. But if I refer to the telephone solutions, my guess is that many > will differentiate routing and addressing in a very simple way (and > this is certainly what the ART (French FCC) wants to hear about - > because this is what users want : IP addresses are to be independent > from the ISP). This means that they will allocate national IDs that > you will be able to use as a NetworkID or as a UserID. And multinationals? Routing? This has been discussed at great length several times in several forums. What if I as an end-user would get a better deal if I locked my self in to a specific provider with their addresses? That is my right! > And you will probably get the UserID for free at birth or creation, > probably additional ones on a small fee and you will pay for the > routing to your NetworkID. and someone hacks that nice system and yoou have rendered all the userIDs insecure and not trustworthy. I still think the ITU proposal is non-workable and is yet a variation of (albeit a poor one) geographical addressing. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZ9236arNKXTPFCVEQItDwCg8rE4VFTabqkqVExcRYwCW0tPbRoAnj3C 4AqJ4qv8yfeS6t3g0vi147ch =8cX2 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-18, at 19.30, Franck Martin wrote: > For the moment what I'm working on is on ensuring that countries can > get assigned a reasonable amount of IPv6 space. A lot of countries are > below radar in the IPv6 assignement. When you have a population of > less than 100,000 and when the IPv6 minimum allocation caters for > every human, pig, horse, dog and grain of sand of that country > > Yes this is a NIC problem, but I wanted to let you know. APNIC is > aware of the needs fo small countries in their constituency, I guess > there is a similar problem in the carabean and other places... The current entry barrier in terms of initial allocation policy is artificial and I think we al know that - and there are many talking about changing this. Let's hope we can get this over and done with fast. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZ49GqarNKXTPFCVEQL65QCg8mvKcFhEDNKgB8XXeVn05cQzf6oAoKdo Uth4p0TgYCGG0U3DgNOeg2Ei =itqA -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-18, at 10.26, JFC (Jefsey) Morfin wrote: > This is for example what the French FCC is investigating in public > questionnaire right now, and I suppose they are not alone. A number > users will get at birth or creation (with additional ones if they buy > them);Their network national ID, warranted by their law so they > can use it in contracts, in life support services, in commercial > relations. They do not want smart solutions, they want sure, secure, > simple, stable, real life services for middle-aged house-wife, elders > and kids. I have long thought that the knowledge of having long (life-long) persistent, well-spread unique personal identifiers are bad was general knowledge. Then again, I guess the US biometric stuff has proven me wrong on that already. > IPv6 will win the day it will not be managed by IETF, not by ICANN, > not by RIRs, but by Govs. and will belong to the international law and > treaties. The customer is not the user. The customer are 192 States > law makers. Show Govs that IPv6 is a sovereignty field for them and > not for the US Gov alone, they will enforce it immediately (and this > is simple to achieve). Today they see IPv6 as another "USivernal" > semi-obligation. The day it is a free governement protected and > accepted service, it will become Universal. This is just what ITU is > investigating : that will please them. All the more than with its NGN > work, it speaks a language they can understand and which appeals on > them. > Let face it, today ITU is far more promoting IPv6 than ICANN and IETF. > And this is good; as Harald puts it: IPv6 is a finished product to be > managed ouside of the IETF (and of ICANN IMHO, hence of IANA, now IANA > has become just an "ICANN function"). I am going for the sake of argument to go along with your reasoning above (although I don't agree). Apparently there is something here to be gained, as we need to 'promote' a particular technology that is under control of intergovernmental treaties. First of all, what would the sales pitch be? I am seriously interested, and as you are arguing for this model you must have an answer. Second, if I understand you correctly above, you are implying this is not a 'free service' today, while it would be under the ITU, sanctioned by governments. Correct? In your view, how would allocations of IP addresses and ports, and protocol numbers be made? Last, how would a address policy process look like under the ITU and international treaties? - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZ43HqarNKXTPFCVEQIUrACgv9Hpg5RmN8vYugS3t0Q3iyr0FYkAnjUR v0FGeE+BWGivra6TgZwNGFPu =14q1 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
IPv4 in the network, please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-08, at 21.55, JORDI PALET MARTINEZ wrote: > Hi Harald, Marcia, > > I'm not sure what is the problem, but as you probably know, we still > don't > have IPv6 in the IETF61 network, which is really bad. > > The worst thing is not getting anyone from the host or whoever is the > responsible, reading the numerous emails about this in this list and > providing at least a reply. Something like "we are working on it", at > least, > will be nice. > > In case they are not reading the list, I guess you know who is the > ultimate > responsible, and can forward him this email. > > Somebody already suggested that if they need some help, is available, > but if > they say nothing, of course, nobody will be able to help. > > Hopefully this is not a situation that last until the end of the week > and > hopefully we make sure next time that actually it doesn't happen even > since > IETF meeting day -1. I want to disagree with Jordi. I want want working IPv4 first. IPv4 seems to be coming and going during the day. This is during the mboned session tonight 11 packets transmitted, 8 packets received, 27% packet loss round-trip min/avg/max = 113.621/129.023/170.027 ms 8 packets transmitted, 6 packets received, 25% packet loss round-trip min/avg/max = 136.386/156.679/208.79 ms I thought it was my Wlan card first but I hear others with problems as well. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQY/sgqarNKXTPFCVEQJ79wCeLAciy58v8mXMQWmH4wsf9V9QNZMAoJYS 2o1n4D77gmGMSjC/CUANkAe/ =khs2 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 is being deployed !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-08, at 22.22, Iljitsch van Beijnum wrote: > On 8-nov-04, at 19:31, Kurt Erik Lindqvist wrote: > >> Well, the RIRs will actually hand out address-space explicitly saying >> they make no guarantees for routability. If you apply for IPv4 PI >> space >> and can only justify the equivalence of a /26 you will get a /26. > > There is a difference between acknowledging that they can't control > how the operator community is going to filter, and telling the > operator community that it's ok to filter out anything smaller than n > while at the same tme giving out blocks that are smaller than n. I don't think any RIR ever have told anyone what can and can't be filtered. And they can't tell the opearator community what to do. Which is EXACTLY why address space is given out without any guarantees of routability. > Whichever way you slice it this is WRONG. Now obviously this isn't the > forum to keep rehashing this (those who can do something about this > either know about the problem now or they are unwilling to fix it > regardless of the input they receive) but I'm afraid as long as people > are going to defend this or redefine the semantics so that it's ok > after all, I'll have to respond and disagree. You lost me. You originally wrote > The IETF (imho) should confine itself to protocol work, The RIRs > should confine themselves to being wise stewards of the addressing > resources, and the ISPs need to worry about the operational > coordination of routing... such is not the perview of either the > IETF, the IANA task, > or the RIRs. My point is that this is exactly what the RIRs have always done. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQY/oqaarNKXTPFCVEQKGswCg/f6BRHuVK4O029vnjnTpplK000UAn1mL SD3dUCY3TnGyqvHher14BP54 =m7Hr -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 is being deployed !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-08, at 14.28, Bill Manning wrote: That's inconsistent with the published policy. >> >>> No. See above. >> >> When there is an inconsistency, you can't fix it by adding more data. >> You need to remove/change something. The fact that the information >> necessary to do route filtering is present in 5 locations and >> policies are created in 4 places doesn't help. >> > it is important to remember that neither the IETF nor the RIR can > manage/conserve the entries in anyones routing/forwarding tables. > The IETF (imho) should confine itself to protocol work, The RIRs > should confine themselves to being wise stewards of the addressing > resources, and the ISPs need to worry about the operational > coordination of routing... such is not the perview of either the > IETF, the IANA task, > or the RIRs. Well, the RIRs will actually hand out address-space explicitly saying they make no guarantees for routability. If you apply for IPv4 PI space and can only justify the equivalence of a /26 you will get a /26. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQY+7pKarNKXTPFCVEQJR0wCgyMC5UjkqSGsXcH+zkedq5LKhrEcAn2PE Y0VTL6bNO9myWgKDKy4vExuK =PhUx -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Root Anycast
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We must be talking about two different Internets. - - kurtis - On 2004-05-19, at 21.46, jfcm wrote: > At 18:12 19/05/04, Kurt Erik Lindqvist wrote: >> > - I talk of real world when you talk of the current (unsecure and >> > overloaded?) implementation of the current DNS architecture. >> >> In what way overloaded? Do you have any pointers? Proof? Data? > > Dear Kurt Eric, > Let not play this, please. Either you think after careful personal > study (or you believe) that the current system is the best solution > the world needs, and that it only calls for some users to be more > educated in using it - and we are on planets apart. This is fine with > me, and the end of a non existing debate. > > Or you think the DNS does not match the IETF "core values" in being > centralized (I do not make that "core value" as described by Harald a > creed, I think they are often outdated, but I fully agree they are a > technical minimum). And, together with ICANN, you think IETF is the > right place to respond ICANN's call for more (ICP-3). So you try to > understand the problem and to imagine solutions. This is what we did. > And I explain the solutions we are subsequently working on. > >> > The problem we face is an old and too large unique system with a >> > robust yet overloaded engine. With all the problems which come with >> > it. We have to split the zones of usage and risks. Either it is >> > planned by IETF or it is done by the users. I suggest it is done >> > together. >> >> Again, overloaded engine in what way? > > I just report on our follow up on this premise. If you do not see it, > I cannot help with details. Just with the alternative. Yu are the > judge. > > The DNS "engine" is made of all the root/name servers and resolvers. > - either you are satisfied with their present tools, organization, > limitations and resulting service, then again I cannot discuss it. > - or you are not, and then the question is to know if your > disatisfaction results from the used solution or from the way this > solution is implemented. > > IMO the problem is not with the solution (software) but with its > architectural deployment and usage. This permits a smooth transition, > using existing and proven building blocks and expertise. But I think > that speed if the essence. One may also disagree. > >> > Then the agreed file >> Agreed by whom? In what way? > > Let me elaborate quickly. The target is not to obtain a file which > pleases anyone as today, but a file which reports on the TLD Managers > entries. So, the point is not who does it but the number of identical > independent results. What follows is for one single national service. > > - National because of the legal and political aspects in many aspects > (risk containment, sensitive information intelligence leaks, justice > obligations, etc.). > - But subsidiarity applies to the regional, local, corporate, private > granularities (I explained what this means in my first mail). > - this means that security and verification will probably repeated 20 > to 50 times accross the world. Once a day in each country could mean > every hour for global issues such as the DNS (the protocol is the same > for every root information [time, radio frequencies, weather, hospital > situation, etc]) > > The process we retained is to have at least four different independent > data collection processes (whatever the processes, starting with a > simple duplication of the NTIA file in the case of the DNS legacy > root). The reason for at least 4 is to have at a majority if needed, > even if one is down. > > There must be five conditions for the result to be accepted (there > could be more?) > 1. there must be no reported alarm (nominal situation) on our > monitoring system > 2. all the results must be identical > 3. there must not be an abnormally large difference with preceding > copy (variance max to be tuned from experience) - to allow reasonable > updates if permitted. > 4. visual review by the four collection managers is positive > 5. there must be no significant (similar to 3) with other partenering > root files on common part of the root matrix. > > If these 5 conditions are not met there will be an investigation and > concerted agreement to be reached among collection managers, or a "no > go" and escalation to Execom and to BoD (or Gov). These conditions (or > more) can be made legal and imposed before a State endorses a Root > Service for its own use and for legal transactions. > > There is a possible alternative: the decisi
Re: Root Anycast
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-05-19, at 00.54, Dean Anderson wrote: > On 18 May 2004, Paul Vixie wrote: > >> The result is a service which has never been "down hard", not ever, >> not for >> any millisecond out of the last 15 years. This is "strength by >> diversity." > > This isn't quite true. There have been multiple server failures. And > if I > recall, I think that there have been quite a few servers (like 12 of > 13) > that have been down at one time in this timeframe. > > But I haven't been keeping close track. If someone has been keeping > operational stats (like outage date, cause, postmortem) on the roots, > I'd > appreciate a pointer to this... So although you don't know, you still like to claim that 12 out of 13 have been down? That's quite a serious allegation. I'd like that have that proved or taken back. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQKuFwKarNKXTPFCVEQJvvwCgpIrHqDjgER0DOUGlBhZbHRlf2usAoIWk STNUBlFr5yD2f/brF0AgoHnJ =NFz5 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Root Anycast
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > - I talk of real world when you talk of the current (unsecure and > overloaded?) implementation of the current DNS architecture. In what way overloaded? Do you have any pointers? Proof? Data? > The problem we face is an old and too large unique system with a > robust yet overloaded engine. With all the problems which come with > it. We have to split the zones of usage and risks. Either it is > planned by IETF or it is done by the users. I suggest it is done > together. Again, overloaded engine in what way? > Then the agreed file Agreed by whom? In what way? > You want to reduce the calls to your system, right? Let stop the > "cache" idea which is something of _your_ system ibn theirs, and > propose them an update of _their_ system - like anti-virus updates > (ever heard that anti-virus run huge 50x1G systems? And let discover > what a user system can bring more to its user owner. So when the user > has started using and enjoying _his_ system, you will obtain what you > want. Why would I want to reduce the number of calls on my system? My system is doing just fine... - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQKuHjqarNKXTPFCVEQJbDQCbBgjOmqDeK5bjzlbzlCVwB+XtkrIAoIpu 7V0w8Yq6Q6qxIKy1XRwtfHuX =863T -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: 13 Root Server Limitation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-05-17, at 00.22, Dean Anderson wrote: > On Sun, 16 May 2004, Thomas Bocek wrote: > >> Hi >> >> Iâm confused with the fact than the number of root servers is limited >> to 13. >> From RFC 3226: >> >> "The current number of root servers is limited to 13 as that is the >> maximum >> number of name servers and their address records that fit in one >> 512-octet >> answer for a SOA record. If root servers start advertising A6 or KEY >> records >> then the answer for the root NS records will not fit in a single >> 512-octet DNS >> message, resulting in a large number of TCP query connections to the >> root >> servers." >> >> A query send to one of the root servers with a long name (length 255) >> shows that the answer is 511 bytes, returning one A and 13 NS records. >> My question is: Why are all 13 NS returned? [snip] > This dubious anycast configuration was discussed and "approved" by the > NAMEDROPPERS Working Group in late November, 2002. To the best of my knowledge there where root-servers anycasted way before this date. And I have no idea why the namedroppers mailinglist (or the IETF for that matter) would have to approve how the root-servers are operated? > Unfortunately for the > anycast discussion, the list then became distracted by discussions > concerning procedural irregularities involving the AXFR-clarify Draft, > which would have altered the DNS AXFR and IXFR protocol to conform to > the > non-standard ISC/BIND implementation, despite a number of other > implementations being able to follow the AXFR and IXFR specifications. > This quickly developed into a discussion regarding abuse by the list > administrator (Randy Bush) with respect to Dan Bernstein, and so the > anycast discussion was abandoned. > > As the IETF list members are perhaps unaware, the charges of abuse by > ISC > and ISC-promoters is hardly new. It is very hard to get real work > done in > the DNS working groups as a result. ISC/BIND promoters have the > working > group tied up with gratuitous alterations to widely implemented > protocols > (eg AXFR-clarify) and irrational and misleading changes (eg IN-ADDR > required) that have been demonstrated to either be security risks or > dangerously misleading security placebo's, and have tried to suppress > dissent on these issues by refusing to accept email, and in the past, > silently discarding email, and otherwise harrassing people who offer > reasoned and detailed objections. > > I and others would probably be more involved in issues like DNSSEC, > and no > doubt more progress would be made, if it weren't for the distractions > of > the mismanagement of the IETF and its working groups. I've got no idea what this has to do with the number of root-servers. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQKitaKarNKXTPFCVEQJ2egCgs69tH2LXGKZI12ZEzhNJ2LVKaVkAoP0s zo+h2jIT17WGxiR4Rkd6k/8p =Vd76 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I thought I needed to pay to get to most ITU standards. But I might be wrong. I can't see how personal closed discussions relate to open standardization. Are you saying that you want to have an open process, as long as you have a direct channel to the chairs in that process? I am not following you. I though the standardization for the IETF was done in public, not in private emails with the chairs. And that that was what made the IETF special. - - kurtis - On 2004-05-13, at 18.34, Dean Anderson wrote: > Of course, this is exactly why the third world doesn't want to have the > IETF in charge in its present form. > > Professional and standards organizations aren't private clubs. > > --Dean > > On Wed, 12 May 2004, Kevin C. Almeroth wrote: > >> This pretty much does it for me: anyone who says they are entitled >> to participate in the IETF immediately goes into my spam bucket. >> >> As others have pointed out, you've done yourself more harm than good. >> I'm entitled to particpate, and I'm entitled to send email to the WG chairs as a participant. One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. Dean Anderson Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf >> > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf > -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQKisgqarNKXTPFCVEQLJrQCgoc/TPKrlLx7QUTXsjkIkjZ8kVVsAn07g f8jJEq6KM4+sTZqp01ScKraY =KuSS -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-05-11, at 23.55, Dean Anderson wrote: > On Tue, 11 May 2004, Joe Abley wrote: > >> For the benefit of less-operational people here who don't see humour >> in >> this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area. > > This block is assigned to EP.NET. I work for an IXP. Are you trying to say that that means that all traffic that passes an IXP means that I am the upstream for that traffic? It doesn't work this way. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQKjlvqarNKXTPFCVEQIevwCfQAG+nR7rSNpkmSGvSmtTsjTEKtMAn03c PTbWNR/gB8VkAwl/P+94/WQZ =0ViT -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Re[3]: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note that I did not mean my comment as sarcasm or irony. If I would have, I would have put a ":-)" after it. I didn't. I am a newbie. I am still having déja vu. - - kurtis - On fredag, dec 5, 2003, at 15:35 Europe/Stockholm, jfcm wrote: > At 21:22 02/12/03, Kurt Erik Lindqvist wrote: >> Hasn't this idea been killed enough? I am a newbie on the Internet >> (only been here since 1988) and _I_ am fed up with this discussion. > > Hi! Kurt, > did not see that one. I will respond it because it may help you > understanding. I am also a newbie as I only been here since 1977 (on > the other side of the "plug") and _I_ keep trying IETF people to > understand the same thing: there is a real world out there. > > The first time I had that discussion was with the first internut to > show up in an international users meeting in Tahoe probably in 1984. I > wish I remember the name of the guy. Could have been Vint from what I > remember, but I think the name was longer. > > It may interest you that I am a peacefull person and I want to reach > consensus. But I have Louis Pouzin involved (we both are on Eurolinc > BoD) who you may know. He specified the first "mail" program at MIT, > the scripts, the end to end datagram, the IP zones (recently Vint > recalled the Internet could have been called "catenet" from his > multiple routes concatenation approach - I think is the necessary > future). I am glad he is not active on this list :-) > > take care. > jfc > > > > > > > > > -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP9DBC6arNKXTPFCVEQLDrACcDdMJv1EkUTiFvSgyK0NCfrm5j8wAoMsv AmCiWpGg4IPEMvnVlOGSoVoS =vmrJ -END PGP SIGNATURE-
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, dec 4, 2003, at 23:44 Europe/Stockholm, Franck Martin wrote: > There are now organisations installing root servers in all countries > that want one. I am the CEO of one of those organizations. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP9Ah2qarNKXTPFCVEQL5JQCfWN6CFuYJA+du0Ybc2KXl6/k+qjcAnRF5 pZmB69DEIrq8HRF1X2tERurT =b7ow -END PGP SIGNATURE-
Re: national security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> > The post KP&Quest updates are a good example of what Govs do not
>> want
>> > anymore.
>> I can't make this sentence out. Do you mean the diminish of KPNQwest?
>> In that case, please explain. And before you do: I probably know more
>> about KPNQwest than anyone else on this list with a handful of
>> exceptions that where all my colleagues doing the IP Engineering part
>> with me. Please go on...
>
> I am refering ("post" KPNQuest) to the reference management lesson
> ICANN gave concerning root management when the 66 ccTLD secondaries
> supported by KPNQuest were to be updated. NO one will forget at many
> ccTLDs, and Govs.
I was there when KPNQwest went down. I think I have concluded that what
you are referring to was a machine called ns.eu.net. That machine has a
history that goes back to the beginning of the Internet in Europe.
Through mergers and acquisitions it ended up on the KPNQWest network.
It was secondary for a large number of domains, including ccTLDs. When
KPNQwest down, the zone content and address block was transfered to
RIPE NCC. As far as I can tell it is still there. TLDs where asked to
move away from the machine over time.
As a matter of fact, several studies the year before KPNQwest went
down, pointed out the problem with having all the worlds TLDs using
just a few machines as slave servers. However, the DNS is designed to
work fine even with one slave not reachable. So even if ns.eu.net would
have gone off-line abruptly, which it never did, people got, and
apparently still have, plenty of time to move. I think this incident
clearly shows the robustness of the current system, more than anything
else.
>> I just fail to see this. What is it with the ITU that will give us
>>
>>a) More openness? How do I as an individual impact the ITU process?
>
> This is not the topic (I come initially from a national point of view)
> and not to disuss but to listen.
> But this is also an IETF separted issue. As deeply involved for years
> in @large issues (ICANN) and far longer political, public, coporate,
> technology development network issues and for having shared for some
> years in the ITU process (at that time CCITT), I think I will say
> "Yes".
>
> 1. As a user I have no impact on IETF ICANN. Not even do not get heard.
IETF and ICANN in this prospect are two completely different
organizations and processes. In IETF, you are making yourself heard.
Quite a lot actually.
> 2. but (and with a big "but" unlil ITU adapts and created an "I"
> sector for us) ITU has the structures and procedures (Focus Groups and
> Members called meetings) just to do that.
>
> You may have studied/shared in the WSIS and observed the way it works?
It certainly doesn't strike me as open at least. I have read the
following : http://www.itu.int/wsis/participation/accreditation.html.
An organization where I have to apply for accreditation doesn't sound
open to me. Actually I am not even sure what WSIS expect as input. To
me it seems as a forum for governments to be seen. With the hope that
they will have a forum where they can raise issues to other governments.
What I am missing is a) The input of the professionals b) How they
expect to use any eventual output.
Again, I fail to see what the ITU process gives that have a clear
advantage over the current IETF process. And as said, there are also
governments who have come to understand this and learnt how to deal
with the IETF process at the same time as making contingency planning.
>>b) More effectiveness and a faster adoption rate?
>
> Probably yes. For a simple reason. Internet is just another technology
> to support users data communications needs. I may find faster, better;
> parallel solutions else where. Competition fosters speed and quality
> or death. As a user I am darwinian about the process I use.
So you are saying that the ITU will provide better standards at fast
speed? That has most certainly not been the case before...
>>c) A better representation of end-user needs?
>
> Certainly. This is a recurring issue. Quote me the way IETF listen to
> end-users needs. I have been flamed enough as a user representative to
> know it. And don't tell me "who do you represent?" or I will bore
> everyone responding. This thread show it. As a user I rose a question.
> Responses:
The IETF makes decisions by rough consensus. If you have a point that
is valid enough, you will get enough people to support you. If not,
life goes on.
> - question are disputed. I learned a long ago that questions are never
> stupid, but responses may be.
No, but the question might tell a lot about who you are and what your
motives are.
> - question asked back to me: who are you. I appreciate that you may
> warn me about KPNQuest to spare us a trolls response. But I wander why
> the author would have any impact on a new question.
Knowing peoples background is always helpful
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> I agree and realize this. However, the let's take that argument out >> in the open and not hide it behind "national security". > > I regret such an agressiveness. I simply listed suggestions I > collected to ask warning, advise, alternative to problems identified > not from inside the internet but from outside. Why don't you simply go inside and find out? There is nothing like first hand knowledge! > I was labelled as a topic of national security because it was to > prepare a menting on national vulnerability to Internet. If it had > been about a Web Information and Services Providers, or User Networks > demands, it would have been the same I know a number of countries that have looked at this from a national perspective. None of them have argued that the ITU is the solution. On the contrary, the distributed control of the Internet is a good value. > I expected warnings, advices, alternative propositions. If you need a > long discssion among specialists to come with that, please do. I am > only interested in an authorized outcome. And we will all thank you > for that. What the collective Internet thinks is documented largely through the IETF process, or related organizations. I think that the issues you are trying to raise are already answered at any point in history as being a reflection of the current set of standards. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8+D+KarNKXTPFCVEQJm9QCgzecWX5+0R1RcADym1rrZHICjvPAAoK2o DBfR0ezNIcNGpKt4bb+J8bGl =HL9l -END PGP SIGNATURE-
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On onsdag, dec 3, 2003, at 04:12 Europe/Stockholm, Franck Martin wrote: > ITU is worried like hell, because the Internet is a process that > escapes the Telcos. The telcos in most of our world are in fact > governments and governments/ITU are saying dealing with country names > is a thing of national sovereignty. What they most of the time fail to > see, is that most registry are willing to hand it over to the > governments provided they DO understand the issues, and not use DNS to > empower telcos in more exclusive licencing power. > > ITU has been also misleading countries by making them think that DNS > issues will be solved at ITU meetings. I have been telling countries > that they must attend ICANN meetings and no other one. When this > happens, US corporations will have less power over ICANN and things > will be better. > I agree and realize this. However, the let's take that argument out in the open and not hide it behind "national security". The countries I have worked with, do have national disaster plans that can handle a IP network completely cut off from the rest of the world. But those plans are made together with the industry, as today you can not have this type of planning without co-operation of the large, world wide companies. Even if the governments own and control many of the telcos of the world, the operation of the sub-sea cables that transport the traffic is mostly run by organizations they have no control over. Best regards, - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP82dC6arNKXTPFCVEQIqZQCcDd1ffRAvtfBjvUSJXfoaw1ilVkQAnRqH V/3ZsmgatgorFVGQYmDmXLcM =yrRB -END PGP SIGNATURE-
Re: Re[3]: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > This being said, I note that this thread is only oriented to > prospective numbering issues. May I take from that that none of the > suggested propositions rises any concern ? > > In particular, that there is no problem with two parallel roots file > if they want to be identical? What would happen if one was hacked? (I > note that this is the current situation of the Internet where two > deliveries of the same file are proposed). Hasn't this idea been killed enough? I am a newbie on the Internet (only been here since 1988) and _I_ am fed up with this discussion. It's a bad idea, for more reasons that I will bother to write down. If you want an exhaustive answer, I suggest you ask SECSAC. > The same, no one comments on secondary source for the root, meaning > that the ICANN unicity is not an intrisic need, provided the > different root files collectors strive to collect the real data from > the TLD Managers (who are authoritative, while the root file is not). > Not a problem to anyone? See above. > No one either comment on private TLDs, or the creation of a virtual > TLD used through Host.txt only. No one objects to the generalization > of users resolvers, the possible resulting dissemination of the root > file to all the users and their resulting ability to fight an ICANN > redelegation what is a major issue at WSIS. Hosts.txt only is a decision by the local system operator. They are free to handle name resolution as they want (well). NIS, NIS+, DNS, or Hosts.txt. If I where them, I would use the same DNS as all the rest of us. My opinion is that his entire thread, is a reiteration that most people while learning IP and the Internet, got thought was a bad idea - and why. It simply lack basic understandings. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8z0jqarNKXTPFCVEQLYCQCfRugvPQNUgkkkj6Hvz8YVV6/D1IwAoPSA z419eHzBgftprNgk+RCyD1bn =QBkK -END PGP SIGNATURE-
Re: Re[6]: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On fredag, nov 28, 2003, at 20:10 Europe/Stockholm, Anthony G. Atkielski wrote: > >> Ah, I see what you mean now. However, the devision is a done deal as >> RFC 3513 mandates that all unicast IPv6 addresses except the ones >> starting with the bits 000 must have a 64-bit interface identifier in >> the lower 64 bits. This has some important advantages, most notably it >> allows stateless autoconfiguration. (However, this could have been >> done >> with 48 bits too.) But it does have the downside you mention by only >> leaving 64 bits for numbering subnets. The practice of giving all >> sites >> a /48 further deminishes the available bits. > > Wow ... it's even worse than I thought! Why bother even going to IPv6? > so you are making claims and comments on something you don't even have bothered to read the basic documentation on. Wow. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8zIyaarNKXTPFCVEQJ5bwCdEXkTSxDyYphqbAQh8mPDPK4CYjsAoIGR cPdEgj4Ws2eiz1ZJv4qMSjbx =fFoK -END PGP SIGNATURE-
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The post KP&Quest updates are a good example of what Govs do not want > anymore. I can't make this sentence out. Do you mean the diminish of KPNQwest? In that case, please explain. And before you do: I probably know more about KPNQwest than anyone else on this list with a handful of exceptions that where all my colleagues doing the IP Engineering part with me. Please go on... > > Consider the French (original) meaning of "gouvernance". For networks > it would be "net keeping". Many ICANN relational problem would > disappear. Ok, enough of references to France/French/European. I am born and grown up in Finland, I have more or less lived in Germany and the Netherlands for 6-36 months, I live in Sweden since 9 years and I have a resident in Switzerland. I have worked on building some of the largest Internet projects in Europe and the largest pan-European networks. Even with governments trying to meet their needs. So I should be the perfect match of what you are trying to represent. And I just don't buy any of your arguments. Sorry. > What would be the difference if the ccNSO resulted from an MoU? It > would permit to help/join with ccTLDs, and RIRs, over a far more > interesting ITU-I preparation. I suppose RIRs would not be afraid an > ITU-I would not be here 2 years from now. As someone who is somewhat involved in the policy work of the RIRs, I really, really, really want you to elaborate on this. [Quotes rearranged] > The complexity is that ICANN wants to be two conflicting things >(American and International) and to organize something multinational. > Vint, you will never change that IANA is part of the Internet and > Internet is the current solution of the world for its > datacommunications. So IANA must be involved. ITU is the way govs > cooperate in communications (data, telephone, TV, radio) and where > they have so many mixed interests that they must be cautious (this is > what protects us, the consumers). So ITU must be involved. > > If you are serious about becoming multinational, you must disengage > from the US Gov. But IANA will never lose its US Flag without ITU. ITU > will never develop an acceptable higher layers capacity (ITU-I) before > long, without ICANN, ccTLD etc. > > So, how long will we have to wait for you to ally (and not to try to > swallow) with ccTLDs and to sit down with Mr. Zao, stop WSIS worrying > and permits jointly care about fostering development and innovation. I just fail to see this. What is it with the ITU that will give us a) More openness? How do I as an individual impact the ITU process? b) More effectiveness and a faster adoption rate? c) A better representation of end-user needs? > The lack of users networks. Multiorganization TLDs Jerry made > introduced as a reality we started experiencing. Just consider that > the large user networks (SWIFT, SITA, VISA, Amadeus, Mnitel, etc.) > started before 85. OSI brought X.400. CERN brought the Web. But ICANN > - and unreliable technology - blocks ULDs (User Level Domains). To be honest, none of those networks are really large compared to the Internet, or in terms of users and especially bandwidth to some of the large providers. And, yes, OSI brought X.400 - but I am not really sure what to make out of that point...:-) > I just note that you never cared about Consumers organizationsn, while > a world e-consumer council would have given you the legitimacy of > billions and the weight to keep Gov partly at large, and satisfied. A > National Security Kit would then be one of the ICANN raisons d'être, > keeping Govs happy. I think that the national governments that are thinking they need control over ICANN in order to handle a national emergency simply needs to understand the problem better. There are non-US governments with contingency planning that works without any of the I* organizations being under the control of ITU. I just guess those have done a better job. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8z1zaarNKXTPFCVEQIl0ACgpdZ2UjHU3BoynpqZWqrXOYfAgPEAniOK +WPzBgPS0MlmT8whXLLEcWup =illt -END PGP SIGNATURE-
Re: Removing features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> - Do not flood root servers with reverse lookup queries for >>> private addresses (I want my traceroutes to work on the >>> inside of the network too, so I long ago configured reverse >>> lookup for private addresses on my internal DNS servers). > >> Kurt Erik Lindqvist wrote: >> Say again? > > Where are all these bogus requests to reverse lookup an RFC1918 address > coming from? There are a hell of a lot traceroutes going on then... Also note that at least at i.root there are a lot more queries with src addresses being RFC1918. This is the same for f.root as far as I can remember. > display purposes; this reverse lookup fails on the local DNS server and > might end up in one of the roots. Well, as for the reverse lookup it should end up with one of the AS112 servers as the in-addr.arpa zones have been delegated. > However, if a reverse lookup zone (1.168.192.in-addr.arpa in this case) > is configured in the DNS server that the host doing the traceroute is > using, and if the correct PTR is configured (1.1.168.192.in-addr.arpa > PTR cisco.arneill-py.sacrament.ca.us) the traceroute correctly > reverse-lookups the first hop and that request never ends up in a root > server. Also, it's faster because it does not waste 5 seconds timing > out > on the request. I won't argue against you. Now, why don't people do this? - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP4zadKarNKXTPFCVEQIk1gCg9wbLn6KW3um4Lg+BbyaBM3WO73QAn1AW BnQMQ5eVfo1zHoprDRQkwFjG =h//K -END PGP SIGNATURE-
Re: Removing features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On måndag, okt 13, 2003, at 18:58 Europe/Stockholm, Michel Py wrote: > > - Do not flood root servers with reverse lookup queries for private > addresses (I want my traceroutes to work on the inside of the network > too, so I long ago configured reverse lookup for private addresses on > my internal DNS servers). > Say again? - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP4wGcKarNKXTPFCVEQIoYQCg1L8Xn3TCLI9OpL79Rl0A7+fiz1cAniBW mN/Mkht8hIilgKGa2mKKq6gt =lqp9 -END PGP SIGNATURE-
Re: Impact from rfc1918 leaks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> | I don't think another 10% load on the root nameservers is a huge
> deal,
> | so I wouldn't use the word "harmful" but I guess this is a special
> case
>
> Again. You'll have to ask the operators of the root-zone if they
> consider 11-14% a big deal. Maybe some of them are listening
Well we as root-server operator will have to take the costs of
upgrading to handle the total query volume10-15% is then quite a
lot.
>
>
> | I read a report that only 2% of the hits on the root servers is both
> | legitimate and useful anyway.
>
> ~From the presentation I refer to which unfortunately is in Swedish but
> you can probably read the numbers anyway... :
>
> http://www.iis.se/Internetdagarna/2003/23-robust-dns/id03-23-lars-
> johanliman.pdf
>
> this is clearly not the case. The rfc1918-queries consistute the bulk
> of bad queries ("DUMMA frågor" on page 4 of the presentation). I must
> however confess ignorance as to what queries are 'useful'. Presumably
> even the rfc1918-queries were deemed useful for someone since they
> were sent in the first place.
The 2% figure I think was from an analysis of f.root-servers.net.
i.root-servers.net seems to be seeing more "valid" queries than f. I
guess these figures are different from each server. I think Liman said
that we where seeing 25% garbage in total. I think queries from and
about RFC1918 addresses was around 20% of those. It would be fun to see
what percentage of the Ipv6 related queries that are for site-local
addresses...
- - kurtis -
-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2
iQA/AwUBP4f0L6arNKXTPFCVEQLr0wCfQ98s0IuFlle09q5Ceu41dzxY0ncAoMde
WOPfR47J5gKXQbD85232h5YK
=uMUn
-END PGP SIGNATURE-
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
By-the-way, Neulevel (.us and .biz) did an "experiment" along these lines back in May of this year. It was short lived. At the time I thought it was a bad thing, and I still do. And at the time I wrote and sent to the ICANN board an evaluation of the risks of that "experiment." .nu have been doing this for a long time AFAIK. - kurtis -
Re: Solving the right problems ...
On onsdag, aug 27, 2003, at 18:20 Europe/Stockholm, Jeroen Massar wrote: The multi6 wg has been working on locator/identifier separation as a way to solve the multihoming in IPv6 problem for a while now. And ever since they haven't progressed much unfortunatly :( Hard to tell. There are two design-teams that are supposed to present in Minneapolis. - kurtis -
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, jun 19, 2003, at 05:18 Europe/Stockholm, Eric Rosen wrote: > People need to understand that the purpose of the Pseudowire stuff > (PWE3) is > to enable service providers to offer existing services over IP > networks, so > that they can convert their backbones to IP without first requiring > that all > their customers change their access equipment. Producing the > protocols > needed to enable migration from legacy networks to IP networks seems > to me > to be quite in the mainstream of IETF. The technical issues, > involving > creating tunnels, multiplexing sessions through tunnels, performing > service > emulation at the session endpoints, are all issues that the IETF has > taken > up in the past, there is nothing radically different going on here. But how many of these protocols do we need? And how do we want this done? We are complaining that the IETF have to much work, and still we replicate the same functionality in several WGs - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvFeN6arNKXTPFCVEQLVIgCfXq5oAs5gjeynps93pJOp/ssGNAMAn1ne a9jFlbHw84uSCivXKDF4Sex7 =kaRD -END PGP SIGNATURE-
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, jun 19, 2003, at 01:17 Europe/Stockholm, Paul Hoffman / IMC wrote: > (Humorously, the very large service provider who doesn't use MPLS in > their core says that it usually only takes one or more sentences to > convince the prospective customer that MPLS is not needed.) My experience as well. I lost count of how many times I had the following conversation : C: But MPLS gives me encryption! Me: Err, nope. C: Oh? But that is what Vendor X and provider Y told me? Me: Have you looked at the technology? C: No Re-iterate. I have had the same discussion with C replaced with provides. That is when I got scared. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvFRbaarNKXTPFCVEQJ2ZQCgxe6vitUPn/VRssdCiXcXeJicTicAnAyk ahH4o/EXIRMcShIVmTKaA9NO =cC4C -END PGP SIGNATURE-
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> If you use LDP, it is NOT a routing protocol. The specific mode of >>> use >>> (targeted LDP) is already described in RFC 3036. The FECs are >>> different, but >>> the FEC TLV was defined in such a way as to be extensible. >> >> And when you want to do this inter-domain? Everything else seems to >> have made it's way into BGP so I think that Pekkas concerns are >> valid... > > That's only because the IETF hasn't made security easy enough, light > enough, or > something. Now some people use the argument that everything should go > into BGP > because "opening another port into the provider network is a security > breach." > Why is port 646 (LDP) any more insecure than port 179 (BGP)? Well, I think it's more to it than this. BGP doesn't traverse firewalls, at least not in most cases. I think the reason more and more is being put into these protocols is because "they are there". It's simply easier than thinking about the implications of doing this. >>> >>> not >>> necessarily go down well with you either, but think of MPLS as a >>> logical FR. >>> Providers do not want to change their infrastructure, e.g., replace a >>> FR cloud >>> with an ATM cloud, then with SONET or GigE. That's mega-expensive. >>> By >>> abstracting the L2 using MPLS, they can provide the L2VPN service >>> without >>> wholesale infrastructure replacement. >> >> Most of these providers have bought what their vendor told them to >> buy, >> but let's not go into that here. >> Somehow I didn't think this comment would go unnoticed. ;-) > > Sheesh! No, let's go there. You're talking about my potential > customers, and I > want to know if they really are so dense that I shouldn't have been > spending all > this time working on a protocol - I could have just given them a > couple of > high-priced tin cans and a piece of string. Notice that I have been one of those customers. Actually one of the largest outside the US. I have spent more time listening and talking to vendors on these issues than I like to think about. What struck me was how often vendors would come and tell me that provider Y bought this, so this should work for you to. When you then asked the vendors to go the economics of these decisions, and also the economics of the alternatives - you get everything from false and fabricated figures to vendors who simply can not answer. I actually remember very few occasions when I got a full explanation of why a certain technology would help me and where I could see the benefits. > Who exactly the IETF is going to be providing protocols for? For > protocols such > as these, it is the providers who deploy them. You claim that most of > the > providers have little or no discernment. Let's give credit to the > providers. > There are a large number of them who know what they are doing. Many > of them > participate in the standards. Providers go with technology that is a) cheap b) hight margin. Did providers start selling MPLS based VPNs (L2 & L3) because the demand was so huge? No, some providers and vendors created the demand. For some providers this works very well and fitted the strategy. Yes, there are providers who work on standards in the IETF. Unfortunately I think they are way to few though. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvFLR6arNKXTPFCVEQJ3LgCgzDrvaeUi0j/xWKhBhPNWic9fC2oAoMEj sTC9ToVkbZP6CRHO/q1uXp64 =rSyl -END PGP SIGNATURE-
Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > If you want to address denial of service issues you need protocol > enforcement points. Protocol enforcement points have so far failed to scale (today called border routers). What you need is to fix a much wider problem. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvCyXqarNKXTPFCVEQLk9QCeKez7+Z+rMZ0NAsTSads75v9bP3wAmgP7 WG3EHWur0S0G+pjg/eahGGTC =mVIP -END PGP SIGNATURE-
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> - we must not overload routing protocols and such infrastructure >> (IMHO, >> this seems an inevitable path the work would go towards..) >> > > If you use LDP, it is NOT a routing protocol. The specific mode of use > (targeted LDP) is already described in RFC 3036. The FECs are > different, but > the FEC TLV was defined in such a way as to be extensible. And when you want to do this inter-domain? Everything else seems to have made it's way into BGP so I think that Pekkas concerns are valid... >> - we must not create complexity by deploying ethernet bridging all >> over >> the Internet. Our work should be focused on making IP work, not >> specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a >> *service*). >> > > Primarily, folks want to use it as in "Ethernet-over-MPLS". That may > not > necessarily go down well with you either, but think of MPLS as a > logical FR. > Providers do not want to change their infrastructure, e.g., replace a > FR cloud > with an ATM cloud, then with SONET or GigE. That's mega-expensive. By > abstracting the L2 using MPLS, they can provide the L2VPN service > without > wholesale infrastructure replacement. Most of these providers have bought what their vendor told them to buy, but let's not go into that here. > >> - it is architecturally wrong: use different subnets, period -- >> that's >> what those are meant for in the first place! > > Use different subnets to create VPNs? I don't understand what you > mean. VPLS > and VPWS address a requirement for multiple domains (aka VPNs), > logically > distinct from and invisible to each other. Pekka is right in that most of the applications of VPNs today could actually be solved as good with "real addresses" and routing across networks. >> Btw. how is this different from currently-specified GRE tunneling? It >> being made a "service"? > > GRE-tunneling is one option, but only for the transport of the VC. > However, you > need a demux field to identify the VC that you are carrying. Carrying > one > customer VC between a pair of PEs is obviously not adequate. L2TPv3? Whats the advantage with this over the existing protocol that the IETF have? > - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvCyBKarNKXTPFCVEQL6DQCfSLe3xKzNpU+Me8j4lFuGJojeu+oAoKAP WdkmzQyNXqX4UfhZdIc8XX1g =iysk -END PGP SIGNATURE-
Re: Last 7 days on the IETF list
On lördag, maj 31, 2003, at 06:12 Europe/Stockholm, Michel Py wrote: Rob Austein wrote Traffic statistics (as seen from my cave, your mileage may vary) for the last seven days on the [EMAIL PROTECTED] mailing list. Thanks for posting this. I was about to join another poster in saying that you should not have posted the bytes; however, on second thought, I like seeing them in the table. Apparently there is a direct correlation between the bytes and the number of messages anyway. It is instructive to see the info. It also (might) show that people are quoting excessively which makes whatever point they where trying to make more or less impossible to read. Unfortunately for the top ones the number of mails correlates to the number of bytes which says something else... - kurtis - PGP.sig Description: PGP signature
Re: The utilitiy of IP is at stake here
How about the cost of legitimate emails that get filtered and never read. Not everyone scans the list to check for false positives. In a major example of false positives, we already have examples of one real cost of spam. AOL (as one example of many) has declared ranges of IP addresses marked 'residential' as invalid for running a particular application. In this case SMTP, but which app is next? There is a 'guilt by association' presumption here by the operations community, which when carried into other applications results in substantially limited value in the core IP protocol. I can see the operators POV. If you have no hammer, take bulldozer. Sort of works, doesn't look pretty but is fast. The cost of handling spam is huge and there isn't much else they can do. OTOH, I do agree with you that this is a threat to IP. I know small ISPs in Sweden who filter out a number of applications such as Kazaa and certain on-line games "as they use way to much bandwidth". This is very dangerous. - kurtis - PGP.sig Description: PGP signature
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
David, let's not mix the problem with provider independent addressspace with the SL issue. The first needs to be solved anyway, and SLs are not the answer. Best regards, - kurtis - What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create "non-routed globally unique space". Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. SLs won't come for free either. Architecture aside, I prefer people that use a service to pay for it rather than the community as such. Then I also happen to think that SLs break the architecture but that is something else... - kurtis -
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
layers above it and a dangerous blow to the hour glass model. Looking at what is going on in the IETF, I think we are talking about first aid rather than trying to prevent the blow as such. That happened along time ago...:-( But yes, we need to protect the architectural model or discuss a new one. I vote for the first, and in both cases we need to decide on that fist, before starting to decide on implementations. So leave site-locals for know. Steve Deering made a wonderful presentation at the plenary in London. More people should read it. - kurtis -
Re: Financial state of the IETF - to be presented Wednesday
Speaking from a purely extremely selfish point of view, as a North American, how much would it help if we were to cut back to one meeting outside North America every 5-6 IETF's, instead of once a year, which seems to be the current rate? I was not able to get travel funding to go to Yokohama, and I will almost certainly not be able to attend the summer IETF in Austria. Oh, you mean we would have NAIETF, APIETF and EMEAIETF? I personally pay a lot less for travel inside the Nordics so perhaps we could have the meeting rotating between Finland, Sweden, Norway and Denmark? Maybe not. - kurtis -
Wlan station overlap.
I can't find the mail address of the IETF56 NOC, but in Continental7 there is a overlap on channel 6 between two basestations, but you might already know that. ietf56 00:0C:30:25:9C:DF 11 15 Managed unknown No (null) ietf56 00:0B:FD:04:16:0A 6 26 Managed unknown No (null) ietf56 00:0B:BE:F8:85:B0 6 27 Managed unknown No (null) Best regards, - kurtis -
Re: Posting statistics for the IETF list
No comment. That the IETF list has taken over as discussion list for DNS related discussions instead of namedroppers? - kurtis -
Re: Warning about the use of abusive language
"Be liberal in what you accept" seems a good philosophy for reading this list... As a very intelligent man told me once - "The good thing about 'Subject' is that you know what you can delete without reading it". - kurtis -
Re: NATs *ARE* evil!
> > ipv6 is working just fine even here at IETF49 venue, it's so much more > > convenient than IPv4, for couple of reasons. > > We can't use IPv6 until multihoming issues are properly solved > and global routing table size and the number of ASes are > controlled to be below reasonable upper bound. If I am reading this right you want a upper bound for routing table size? Well,considering the problems some operators have to aggreagate maybe that would be a good idea...:) - kurtis -
Re: Congestion control
I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott >
Re: Congestion control
I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott >
