[EMAIL PROTECTED] Guerilla Party Events for Thursday
[EMAIL PROTECTED] Guerilla Party Events for Thursday **I Need a Pen so I Can Remember Where to Add My Time Capsule Entry Day** Today, is I need a pen day a lovely little bugger with the URL for [EMAIL PROTECTED] stuff on it. These are a nifty accessory in office meetings when sporting the [EMAIL PROTECTED] tattoo you know, gives you that coordinated look. Pick up your pen at the [EMAIL PROTECTED] table. In case you havent read this far before, I will remind you that these are first-come, first-served and will be placed on the table at random times during the day. Be mannered and assign randomly. [EMAIL PROTECTED] Time Capsule** Today is the day that we open the vault and you start predicting the future. Tell us what you see for the [EMAIL PROTECTED] Well collect entries starting today and close the vault during IETF66 in Montreal. The vault will be buried online somewhere and be opened during IETFs 25th anniversary in 2011. So, shine up those crystal balls, summon your best hallucinations and predict your favorite future scenarios for the IETF and the Internet. Youll be glad you did. (Or, even better, you might give yourself a huge laugh in 5 years.) Go here: http://ietf20.isoc.org and choose the Time Capsule link. It will open after noon Dallas time. [EMAIL PROTECTED] Social Video Now Available** Now playing in the [EMAIL PROTECTED] Theatre that looks remarkably like a table in the registration area: video shot on Tuesday at the social. Listen and learn from David Clark. Catch Ray and the IETF originals. Laugh at the toasts. Drool over the cake, the food, the beer. Its all there for your viewing pleasure. Prefer still pictures that you can see whilst in a working group? Check out the fabulous photography of Patrik Fältström at http://stupid.domain.name/gallery/internet/ietf/ietf-65 start at roughly 9066. For the folks that arent onsite, well be archiving the video on the web in a week or two. Get some fiber installed and then watch it on your monitor. Think you need this on a DVD? Let me know and well see about making some dups. [EMAIL PROTECTED] Trivia** Visit todays trivia event at http://ietf20.isoc.org/trivia/. Everyone who plays and sends in their name today will get a free fabulous embroidered [EMAIL PROTECTED] T-shirt. This is your last chance. Youve seen the t-shirt by now. You know this is a good thing. If you were a winner for Wednesdays event, you should have received an email from me telling you so. Pick up your prize during the course of the IETF65 meeting in the ISOC office. Office hours will be posted with the winners list on the [EMAIL PROTECTED] table. The ISOC office is at the Opal Room on Tower lobby floor across from Business Center. **Miscellany** [EMAIL PROTECTED] Guerilla Partying is sponsored by ISOC for IETF65. This is for hilarity. None of your registration fees were used to support these activities. No plants were harmed during the planning process. (Okay, a few might have been picked but definitely not inhaled.) Yes, there will be different activities each day. And, if you dont want to pay attention to the [EMAIL PROTECTED] stuff because it makes you feel too cool or you are busy trying to catch up on all the sleep youve missed this week, delete these messages. **Wednesdays Trivia** But first, more stuff on Tuesdays trivia 1. One IETF attendee appeared on more than a dozen IETF name badges at the Stanford IETF -- name him or her. Milo Medin. From Steve Casner: This was a small revolt against pressure to wear a name badge during the IETF meeting. I don't recall who picked Milo's name to be the one that was replicated, but I can say that it is a shame we don't have Milo partcipating in IETF any more. Scott Brim added: It might have been me. I think Elise Gerich and/or Tracy LaQuey (Parker) were involved. We should definitely track down Milo. Now for the Wednesday info 1. Most protocols are designed as two party protocols, but one early protocol still in use today can be used as both a two party and three party protocol. Name it. FTP. You gotta love it. Good stuff is good stuff. 2. Name the IETF meeting where it was possible to swim in the ocean, walk past the beach bar, pick up an alcoholic slurpee and walk straight into the plenary session. Cocoa Beach... and Scott Brim did just that minus the slurpee. It must be time to go back there, isnt it? Hurricane season is coming soon. Dallas in monsoon. Cocoa Beach in Julys hurricane season. Theres a pattern there . 3. What was the name of the first broadly deployed protocol that had a capability to transfer email? FTP. Gosh, is today all about FTP? 4. What is an IMP? IMP - Interface Message Processor - Packet Switch on the ARPA Net. This is SO easy. Seriously. IMPs were pretty giant contraptions as I recall. Heres a bit more trivia and a picture:
Re: Last Call: 'Experimental Procedure for Long Term Suspensions from Mailing Lists' to Experimental RFC
(Though I agree with most of what Harald said, I will respond on-list only to Margaret.) Margaret Wasserman [EMAIL PROTECTED] wrote: I generally support publication of this draft as an Experimental RFC, I was never able to support it; but until the GENAREA meeting, I regarded it as a necessary evil and was careful to not obstruct it. (I must immediately point out that good people _often_ propose a necessary evil, and I am 100% convinced Sam is a good person.) and I hope that the IESG will use this mechanism to support more moderate and more effective mailing list control over the next 18 months. It would be far more productive for IESG to publicly state that they will entertain no more BCP83 indefinite-suspensions until an acceptable alternative is tried. (And there's a very obvious alternative: returning to the increasing-length suspensions that inadvertently disappeared during the adoption of BCP83. The IESG should do this, BTW, in self-defense against the DoS attack which BCP83 is becoming against the IESG itself. To adopt Sam's proposal, IMHO, would open the IESG to an _additional_ level of DoS attacks against their actual functions. (I could never, BTW, have raised my hand to Brian's question, Who thinks this is a bad idea? because almost everyone would perceive that as a lack of trust of the current IESG members.) I consider this a good stop-gap measure to provide the IESG with more flexibility while we take longer-term steps to determine what type(s) of mailing list control are acceptable and reasonable for use within the IETF, and until we can update our BCPs to reflect those decisions. I can't think of any good way to say what needs to be said here. :^( Let me try this one: (Preface this with a disclaimer: I am a stauch Republican, strongly committed to supporting George Bush for the remainder of his term.) There are a lot of Americans who realize the dangers inherent in the so-called Patriot Act. George the Second found himself asking for powers he must have known would be abused, and IMHO proposed the Patriot Act as a necessary evil. It was by no means the first time such a response to a perceived threat has happened. It's not even the first time in the rather short history of the United States. I suggest thinking back to the Spanish Inquisition... Please don't forget that the Patriot Act was adopted as a temporary emergency measure. Everyone now recognizes that there's no possibility it will go away during George Bush's term in office. The temporary has a long history of outliving the permanent, especially in what we like to call representative bodies. My point is, there's nothing in Sam's proposal to ensure that the experiments which it might produce will be more moderate. Let me repeat my point: However much Margaret may hope that the IESG will use this mechanism to support more moderate... measures, there's nothing in Sam's proposal which ensures that. I see a _lot_ of sentiment for _less_ moderate measures. I see every reason for the IESG to adopt them as experiments in self-defense against the DoS which BCP83 represents. I see going back to BCP83 as so unpleasant to IESG members that the experiments will be extended. This experiment will also give us an opportunity to try some different mechanisms for mailing list management and to gain valuable experience regarding what works and what doesn't. We don't need Sam's proposal in order to do this: we only need to write up a mechanism in terms of an experiment, and agree to try it as an individual experiment. Sam's proposal is, in essence, to turn the IESG into a representative legislative body. IESG members, if they don't instinctively realize how much of a DoS against their proper functions this may be, should look carefully at existing representative legislative bodies and ask folks who have served on them what it's really like. During the Gen Area meeting today, it was asserted that if this experiment is successful, this document might become a BCP essentially as written... I have some major concerns about the idea that we would be running this experiment with a goal of making this particular draft a BCP. I'm _very_ glad to hear that. First, I am not sure how/if the community will have enough visibility into the results of this experiment to reasonably determine whether it has been successful. That is an unknown, certainly. I would predict that unless somebody outside the IESG has specific reporting responsibility, we won't. Will the IESG be expected to provide any reports on which types of experimental mailing list control do/don't work? That, alas, doesn't really matter. The IESG will _not_ have the time to produce meaningful reports. :^( Do we have any measures, even subjective ones, that could be used to determine whether things get better or worse during the period of this experiment? I can guarantee a constituency which will
Re: Making IETF happening in different regions
Jordi, On Thu, Mar 23, 2006 at 06:11:06PM -0600, JORDI PALET MARTINEZ wrote: We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. Why would we go for the average instead of the cheapest ? Overall price of a meeting location is an easier criteria to measure and more fair than all kind of political considerations. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. my mind just boggled. or my bogometer just pegged. no, this does not seem at all fair. nor reasonable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
About cookies and refreshments cost and abuse
Hi, I will like to make an observation about something that captured my attention the last few meetings. I frequently see in meetings people filling up their back-packs with drinks, fruits and cookies. I'm not talking just about one extra drink. I'm talking some times even about people leaving the meeting area after getting the back-pack full in the afternoon break. I will call this abuse towards the rest of us. I don't think suggesting that we don't get the cookies and drinks or that they should be paid as an extra, if you want them, is reasonable. However, is clear that is a *VERY* important cost of EACH meeting, and seems unreasonable to don't pay attention to this and to try to serve our real needs, instead of being in the situation of over/underestimating that, which brings to the situation of not having cookies for all of us. So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. If you consume those, you can buy as many extra as you need and pay for the real cost. Remember that is not only the cost of each cookie or drink, but the tax and service charge. You can make your own guess about the cost if a bottle of water cost 4-5 USD + tax + service (times 5 days, times 3 breaks a day, times 1.400 people). This is what IETF pay for each meeting just for drinks. Also I'm sure that in most of the cases if you need more than the average, some of your colleagues will not have consumed all their own, so it will be easier to get some more at no cost. But clearly, abuse will not be paid by all of us. Regards, Jordi ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be At 07:27 PM 3/23/2006, Keith Moore wrote: We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. my mind just boggled. or my bogometer just pegged. no, this does not seem at all fair. nor reasonable. Keith ___ 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: Making IETF happening in different regions
So you mean you think is reasonable and fair going for the cheapest even if every time more and more people can't attend because a government decides not to grant visas ? I'm feeling very embarrassed and concerned hearing that. I guess our concept of fairness is quite different. Precisely following your recommendation we are being politically driven, instead of openly-in-the-IETF-way driven. Regards, Jordi De: David Kessens [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 16:24:34 -0800 Para: JORDI PALET MARTINEZ [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Making IETF happening in different regions Jordi, On Thu, Mar 23, 2006 at 06:11:06PM -0600, JORDI PALET MARTINEZ wrote: We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. Why would we go for the average instead of the cheapest ? Overall price of a meeting location is an easier criteria to measure and more fair than all kind of political considerations. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be Well, that's how I interpreted it also. What I found mind-boggling was the idea that companies that volunteer to host one meeting would somehow be willing to subsidize meetings held elsewhere. Last I knew it was already quite difficult to find sponsors, and somehow this doesn't seem like a good way to express our gratitude to them for their generosity. I have also been of the impression that our hotel bills and meeting fees were paying for most of the cost of our meetings, and that the sponsors were mostly providing local logistical support and paying for incidental costs - terminal room and wireless, t-shirts, subsidizing the social, etc. And since the meeting fees are more-or-less constant and independent of location, to me it seems like the US-only _attendees_ are already partially subsidizing the cost of overseas meetings. Which doesn't seem entirely fair but might be reasonable - unlike the idea to penalize _sponsors_ of US meetings. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
So you mean you think is reasonable and fair going for the cheapest even if every time more and more people can't attend because a government decides not to grant visas ? you're conflating two problems - cost and immigration laws. having fewer meetings in the US is a reasonable response to US immigration law. asking US sponsors to pay for the additional cost of holding those meetings outside of the US is not reasonable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Except of course that many of the US Sponsors are in fact global companies anyway. Think about the list of recent and future sponsors. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 23 Mar 2006, Keith Moore wrote: So you mean you think is reasonable and fair going for the cheapest even if every time more and more people can't attend because a government decides not to grant visas ? you're conflating two problems - cost and immigration laws. having fewer meetings in the US is a reasonable response to US immigration law. asking US sponsors to pay for the additional cost of holding those meetings outside of the US is not reasonable. Keith ___ 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: Making IETF happening in different regions
Keith, On Thu, Mar 23, 2006 at 07:46:21PM -0500, Keith Moore wrote: I have also been of the impression that our hotel bills and meeting fees were paying for most of the cost of our meetings, and that the sponsors were mostly providing local logistical support and paying for incidental costs - terminal room and wireless, t-shirts, subsidizing the social, etc. These costs vary a lot as well: telco costs are very differrent in various locale, local staff cost is very different, social cost depends a lot on the location etc. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Except of course that many of the US Sponsors are in fact global companies anyway. Think about the list of recent and future sponsors. sure, but the sponsors get some leeway in where meetings are held (since we're more likely to hold a meeting in an area where someone is willing to sponsor it), and one of the factors in a sponsor's decision is probably cost. so if we say to our potential sponsors, sure you can host a meeting in city X, but you're going to have to pay for it as if it were in city Y, somehow that doesn't seem likely to fly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
On Thu, 23 Mar 2006, Keith Moore wrote: Except of course that many of the US Sponsors are in fact global companies anyway. Think about the list of recent and future sponsors. sure, but the sponsors get some leeway in where meetings are held (since we're more likely to hold a meeting in an area where someone is willing to sponsor it), and one of the factors in a sponsor's decision is probably cost. so if we say to our potential sponsors, sure you can host a meeting in city X, but you're going to have to pay for it as if it were in city Y, somehow that doesn't seem likely to fly. Bear in mind that potential sponsors like to host meetings where they actually have local presence. Having people on the ground for months before a meeting is a way better recipe for success then stagging it somewhere else and installing it on friday before the meeting started. If you liked the network for this meeting bear in mind that the people putting it together have been working on it since like october. joelja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
About cookies and refreshments cost and abuse
Hi, I will like to make an observation about something that captured my attention the last few meetings. I frequently see in meetings people filling up their back-packs with drinks, fruits and cookies. I'm not talking just about one extra drink. I'm talking some times even about people leaving the meeting area after getting the back-pack full in the afternoon break. I will call this abuse towards the rest of us. I don't think suggesting that we don't get the cookies and drinks or that they should be paid as an extra, if you want them, is reasonable. However, is clear that is a *VERY* important cost of EACH meeting, and seems unreasonable to don't pay attention to this and to try to serve our real needs, instead of being in the situation of over/underestimating that, which brings to the situation of not having cookies for all of us. So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. If you consume those, you can buy as many extra as you need and pay for the real cost. Remember that is not only the cost of each cookie or drink, but the tax and service charge. You can make your own guess about the cost if a bottle of water cost 4-5 USD + tax + service (times 5 days, times 3 breaks a day, times 1.400 people). This is what IETF pay for each meeting just for drinks. Also I'm sure that in most of the cases if you need more than the average, some of your colleagues will not have consumed all their own, so it will be easier to get some more at no cost. But clearly, abuse will not be paid by all of us. Regards, Jordi ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
the iab net neutrality
I didn't make it to the mic fast enough at the end, but Brian's comment about the proposal to outlaw diffserv actually gets to the heart of why the IAB needs to take specific stands and make public comments. Telling the telco's they are evil is not the point. General statements of principle or observations of past behavior like 'walled gardens are not conducive to open application innovation and frequently result in additional layering complexity to traverse the walls', or 'allowing people to elect going to the head of the line is what the QoS toolset is about'. I am not sure what the right language is but there is probably something the IAB could say about misusing the tools to effectively set up an extortion/protection racket being a possible side effect that regulators might want to consider, but that cutting off the tools outright would actually hamper some potential new service and application development. The point is that if the IAB stands back without making any statement there will be no guidance about the impacts of various business/deployment models. Something along the lines of 4084 that takes no particular position of right or wrong, but identifies the consequences of potential actions might help to stabilize the public debate. After all even open application development might be considered wrong by some, but when coupled with the observation that it happens anyway with more complexity and cost might get all the fundamental issues on the table. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: About cookies and refreshments cost and abuse
So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. I also did this several times, but I believe what I got will definitely less than what you would like to plan to distribute in total. Remember that is not only the cost of each cookie or drink, but the tax and service charge. You can make your own guess about the cost if a bottle of water cost 4-5 USD + tax + service (times 5 days, times 3 breaks a day, times 1.400 people). This is what IETF pay for each meeting just for drinks. If some other people come out and say disbused., that will be fair. But if those word is come from future organizers, I can't imagine what it really means. What I want to ask is: organizer is equal to IETF? -Hui +���z��y�'�+���jwb�ƭ��!'ڟ�y�'~'^�ؚ��ݙ��z-y֧��ں�h�,�v�!����z��z+�v�b�隊V��+-jG���z�ʋ��^�{^�ם���'���^jǧ�؟��^���ze�隊V���'j�h�ț���uץzע*.^�̬�颚g���^�+az��~!ޞ�m�觵��y��r*bz{r�鮲)��b�隊Z+j�Zr���+v+�����{^��-�^�ֆ)^��Z���u��z��}�+��$y�h�� +��y������'���+r~�ڟ'(���z0�'!�(!��}��y�~�b�隊___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
This directly relates to the Skype discussion during the plenary. Skype will, if necessary, tunnel media on port 80 and port 443. To some extent, the debate also highlights a lack of usable protocol tools: One reason, albeit likely not the only one, that there is talk about per-source wholesale charging for improved QoS is that we don't currently have a viable inter-provider retail mechanism that allows individuals and small companies, for example, to request and pay for a fixed-bandwidth pipe between random points on the Internet on short notice. The inability to offer such services also biases things like IPTV towards being provided by those owning the wires and DSLAMs, rather than third parties, even without explicit discrimination. Henning Tony Hain wrote: I didn't make it to the mic fast enough at the end, but Brian's comment about the proposal to outlaw diffserv actually gets to the heart of why the IAB needs to take specific stands and make public comments. Telling the telco's they are evil is not the point. General statements of principle or observations of past behavior like 'walled gardens are not conducive to open application innovation and frequently result in additional layering complexity to traverse the walls', or 'allowing people to elect going to the head of the line is what the QoS toolset is about'. I am not sure what the right language is but there is probably something the IAB could say about misusing the tools to effectively set up an extortion/protection racket being a possible side effect that regulators might want to consider, but that cutting off the tools outright would actually hamper some potential new service and application development. The point is that if the IAB stands back without making any statement there will be no guidance about the impacts of various business/deployment models. Something along the lines of 4084 that takes no particular position of right or wrong, but identifies the consequences of potential actions might help to stabilize the public debate. After all even open application development might be considered wrong by some, but when coupled with the observation that it happens anyway with more complexity and cost might get all the fundamental issues on the table. Tony ___ 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: Guidance needed on well known ports
Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port, reserve it for resolution (e.g., like the RPC portmapper works). But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. About the only reason I can see that that would not be desirable would be to avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might avoid this RTT too, but in that case that benefit doesn't outweigh the costs.) The obvious way to do it, which is have the ICP use the strings directly (as the CHAOS protocols did) is not really feasible now - it would require a change to TCP. That could be done using a late-binding trick like we used for string-based source routing (www.isi.edu/datarouter); we could have a TCP option where the service name occurs (as below), and send it at first to the 'portmapper' port, which would demux it and return it. That does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. Joe Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Furthermore it's increasingly necessary that applications be able to work in environments that do not use DNS - such as ad hoc networks or networks that become isolated. Also a good point. Probably the worst problem with destination port numbers is that there aren't enough of them. That's probably something that needs to be addressed in TCP and UDP No, 65K is probably enough (because, recall that a single port can have connections to hundreds of thosands of foreign ports) *provided* that we don't have to assign a well-known port to each application. It's the concept of well-known ports that's broken, not the provision for 65K ports. Noel ___ 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: Guidance needed on well known ports
Steven M. Bellovin wrote: On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel Chiappa) wrote: Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? Exactly, except to use a TCP option rather than putting the port name in the data stream - where it isn't available until the data is already being exchanged (and ack'd). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: From: Steven M. Bellovin [EMAIL PROTECTED] Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? You know, as I was typing that, I was thinking I'll bet someone has something that does this, and I just don't know about it, and I'm going to look dumb as toast... Sigh... :-) Which leaves us the obvious question: why aren't more people using TCPMux, if it already exists? Because it relies on data and reply is passed in-band. It means that the application ends up thinking the connection is established even if it would have failed. Putting the info in an option is a better solution, since the SYN-ACK can depend on whether the port resolution was successful. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
PS... Joe Touch wrote: Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port, reserve it for resolution (e.g., like the RPC portmapper works). But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. About the only reason I can see that that would not be desirable would be to avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might avoid this RTT too, but in that case that benefit doesn't outweigh the costs.) The obvious way to do it, which is have the ICP use the strings directly (as the CHAOS protocols did) is not really feasible now - it would require a change to TCP. That could be done using a late-binding trick like we used for string-based source routing (www.isi.edu/datarouter); we could have a TCP option where the service name occurs (as below), and send it at first to the 'portmapper' port, which would demux it and return it. That does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: An absolutely fantastic wireless IETF
I'd like to second that. Great job! dbh -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 9:58 PM To: ietf@ietf.org Subject: An absolutely fantastic wireless IETF Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Harald ___ 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: Making IETF happening in different regions
Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. When these participants from the rest of the world want to host in their own regions, they have a higher sponsoring cost. On the other way around, most of the sponsors are typically big companies, which despite being from AP, EU or NA, basically try to make it cheaper to keep their cost down. Regards, Jordi De: Michael StJohns [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 19:34:21 -0500 Para: Keith Moore moore@cs.utk.edu, [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Making IETF happening in different regions What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be At 07:27 PM 3/23/2006, Keith Moore wrote: We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. my mind just boggled. or my bogometer just pegged. no, this does not seem at all fair. nor reasonable. Keith ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
That will be correct if they are really US sponsors, which don't seem to be the case most of the time. Regards, Jordi De: Keith Moore moore@cs.utk.edu Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 19:49:16 -0500 Para: [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Making IETF happening in different regions So you mean you think is reasonable and fair going for the cheapest even if every time more and more people can't attend because a government decides not to grant visas ? you're conflating two problems - cost and immigration laws. having fewer meetings in the US is a reasonable response to US immigration law. asking US sponsors to pay for the additional cost of holding those meetings outside of the US is not reasonable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
Perhaps someone could document what was done differently this time, so that all may learn the secret? -teg On Thu, 23 Mar 2006, Harald Alvestrand wrote: Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Harald ___ 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: Making IETF happening in different regions
Making the sponsorship cost in different regions shared among all the meetings will not significantly increase the sponsoring cost of those in US/Canada, but will actually help to host more meetings everywhere, according to the figures that I know. It has not been, at all, my intend to complain about the sponsors, absolutely on the contrary. It is great that companies like Nokia (in the case of this meeting), take the lead to solve the IETF problem of lack of adequate planning in the last couple of years to find venues and hosts. Is the only reason we can meet here this week, because Nokia. I'm convinced that this situation is going to improve with the new administrative structure, actually is already happening. To make it clear: Many thanks to Nokia and all the sponsors ! It is fantastic. I think there is a big misunderstanding from the participants about how much a meeting actually cost (and in different regions). What is clear is that: 1) The hotel bills may contribute a bit to the cost of the event, but not really so much as you believe, and seems to be very dependant on the location. 2) The fees only cover a small portion of the cost. 3) Long time ago the host responsibility was basically to provide the network/connectivity, terminal room and if they wish so, organize the social. This is no longer true and at least since Yokohama (I may be wrong), the host need to contribute with a big amount of money to make it possible. I will say that today we can't talk anymore about host, but sponsor(s). Regards, Jordi De: Keith Moore moore@cs.utk.edu Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 19:46:21 -0500 Para: Michael StJohns [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be Well, that's how I interpreted it also. What I found mind-boggling was the idea that companies that volunteer to host one meeting would somehow be willing to subsidize meetings held elsewhere. Last I knew it was already quite difficult to find sponsors, and somehow this doesn't seem like a good way to express our gratitude to them for their generosity. I have also been of the impression that our hotel bills and meeting fees were paying for most of the cost of our meetings, and that the sponsors were mostly providing local logistical support and paying for incidental costs - terminal room and wireless, t-shirts, subsidizing the social, etc. And since the meeting fees are more-or-less constant and independent of location, to me it seems like the US-only _attendees_ are already partially subsidizing the cost of overseas meetings. Which doesn't seem entirely fair but might be reasonable - unlike the idea to penalize _sponsors_ of US meetings. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
On Mar 23, 2006, at 21:58, Harald Alvestrand wrote: Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Mmm... well, my laptop (Mac Powerbook) fell off the b/g network several times, mostly during plenary sessions, but the problems were brief, and I usually had no trouble getting back on. It wasn't perfect, but very much improved over previous meetings. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa [EMAIL PROTECTED] wrote: Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. You may be interested to know that this is the direction we took with Multicast DNS and DNS-based Service Discovery (what Apple calls Bonjour). Every machine runs a little process called 'mdnsd' that answers peer-to-peer SRV queries. The registry of application names (i.e. protocol names) is currently maintained at: http://www.dns-sd.org/ServiceTypes.html Right now there are a couple of hundred application-layer protocols implemented that work this way. They bind to zero, get a random port assigned by the OS, and then register that port with the local 'mdnsd' service. The 'mdnsd' service also offers a workaround for the limitations of NAT. If you have a NAT gateway that speaks NAT-PMP (or the UPnP equivalent), then when the application registers its port with the local 'mdnsd' service, mdnsd talks to the NAT gateway, gets a public-to-private inbound port mapping created, and then mdnsd writes an SRV record into your DNS server (requires permission to update a DNS subdomain where Secure DNS Update is enabled) giving the *PUBLIC* IP address and port for your service. The result of this is that when you turn on Personal File Sharing on your Mac at home behind a NAT gateway, then if you want to, you can advertise that service globally. The port number won't be the usual well-known port for Apple Personal File Sharing, but as long as the client looks up the service via SRV record, it will find the correct port to connect to. Details are given at: http://www.dns-sd.org/ClientSetup.html Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Keith, Is difficult to calculate with concrete figures, but it will not be as X and Y, but a point in the middle. It will also be a more open process. Today, in my opinion, having to negotiate with each possible sponsor in secret, is a broken concept, and against our openness. I agree that there should be some degree of flexibility, but in the order of 10% or so, not 100%. Regards, Jordi De: Keith Moore moore@cs.utk.edu Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 20:05:37 -0500 Para: Ole Jacobsen [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Except of course that many of the US Sponsors are in fact global companies anyway. Think about the list of recent and future sponsors. sure, but the sponsors get some leeway in where meetings are held (since we're more likely to hold a meeting in an area where someone is willing to sponsor it), and one of the factors in a sponsor's decision is probably cost. so if we say to our potential sponsors, sure you can host a meeting in city X, but you're going to have to pay for it as if it were in city Y, somehow that doesn't seem likely to fly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
It will also be a more open process. Today, in my opinion, having to negotiate with each possible sponsor in secret, is a broken concept, and against our openness. I'm a lot more concerned about openness in IETF protocol development. some kinds of negotiations really do need to be done in secret. IMHO, having protocol engineers who know next to nothing about meeting logistics try to dictate such terms is a broken concept. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Actually this can be seen as an additional way to bring the sponsor local cost down. There are several factors: 1) We bring the overall cost down by adequate anticipated planning. 2) The potential host prefers to host in the place where they have better local support, is more convenient for them, or whatever. 3) The monetary contribution is the same in all the locations. 4) The local expenses, moving people, etc., get down because the sponsor is choosing the venue of their preference. At the end the venue selection is not biased by the cost difference, because the sponsor want to bring down (3), which actually could mean increase their non-monetary cost (4). The results is also better for all (even participants), because the logistics and local-planning is done more coherently. Regards, Jordi De: Joel Jaeggli [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 17:11:13 -0800 (PST) Para: Keith Moore moore@cs.utk.edu CC: Ole Jacobsen [EMAIL PROTECTED], ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions On Thu, 23 Mar 2006, Keith Moore wrote: Except of course that many of the US Sponsors are in fact global companies anyway. Think about the list of recent and future sponsors. sure, but the sponsors get some leeway in where meetings are held (since we're more likely to hold a meeting in an area where someone is willing to sponsor it), and one of the factors in a sponsor's decision is probably cost. so if we say to our potential sponsors, sure you can host a meeting in city X, but you're going to have to pay for it as if it were in city Y, somehow that doesn't seem likely to fly. Bear in mind that potential sponsors like to host meetings where they actually have local presence. Having people on the ground for months before a meeting is a way better recipe for success then stagging it somewhere else and installing it on friday before the meeting started. If you liked the network for this meeting bear in mind that the people putting it together have been working on it since like october. joelja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
I don't think the meeting fees could actually go down, may be more in the other way around if we are realistic with the cost figures. Actually the cost is already high for a sponsor, and I believe trying to get more from the industry (or other kind of sponsors) for each meeting will be really difficult. Regards, Jordi De: Andy Bierman [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 19:34:00 -0800 Para: [EMAIL PROTECTED] CC: Keith Moore moore@cs.utk.edu, ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED], Michael StJohns [EMAIL PROTECTED] Asunto: Re: Moving from hosts to sponsors Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Below, in-line. Regards, Jordi De: Ned Freed [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 16:38:42 -0800 (PST) Para: JORDI PALET MARTINEZ [EMAIL PROTECTED] CC: ietfietforg ietf@ietf.org Asunto: Re: About cookies and refreshments cost and abuse Hi, I will like to make an observation about something that captured my attention the last few meetings. I frequently see in meetings people filling up their back-packs with drinks, fruits and cookies. I'm not talking just about one extra drink. I'm talking some times even about people leaving the meeting area after getting the back-pack full in the afternoon break. Um, how do you know this isn't a designated fetcher carrying stuff back to some design team huddled over a table off in some corner somewhere? I really doubt it. I think I can differentiate that at least in a majority of the situations, for several reasons difficult to explain. This is not at all unreasonable - I've done it myself numerous times for groups in the past and I've had it done for me several times. In fact earlier today someone was kind enough to grab an extra drink for me, which I then consumed on the spot. Agreed, but he/she could get your ticket for doing it. I will call this abuse towards the rest of us. I don't think suggesting that we don't get the cookies and drinks or that they should be paid as an extra, if you want them, is reasonable. Agreed. I used to be less sensitive to needs in this area, but these days I have to have a little snack to get me through or I start to feel sick. Having everyone run off to fetch such things does not scale very well. However, is clear that is a *VERY* important cost of EACH meeting, and seems unreasonable to don't pay attention to this and to try to serve our real needs, instead of being in the situation of over/underestimating that, which brings to the situation of not having cookies for all of us. So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. I suspect the handling of such tickers would cost quite a bit more than the food it would save. But by all means price it out and see. Agreed, in may happen, but I think that can be negotiated with the hotel, so doesn't mean an extra cost. I also have seen alternative models, such as recently in APRICOT/APNIC, where you got the tickets and you drop them in a box when you queue to get your food/drink. A waiter taking control of the food logistics and at the same time about the possible abusers at every food spot can quickly distinguish if something seems to be abnormal. Ned ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Andy, I have been involved as local host now for two times (although I wasn't very local this time ;-)). I agree that it doesn't make sense to build a network each and every time completely from scratch. It is an enormous effort to beg potential sponsors for accesspoints (or spend a lot of money to buy them), to figure out how to build a terminal room and how to equip it, to buy servers and install monitoring software that gets wiped out right after the meeting to mention just a few examples. Luckily, we and the very experienced group of volunteers that helped us did have some memories (nightmares?) from previous meetings but it would have been way more efficient if a lot of the building blocks were simply already in place before a host even volunteers to be the host (and I think a host would more easily take on this role if the job was a bit more manageable). I personally believe that we would be better off if the same experienced (paid for) group would build the network each and every time with the same equipment owned by IETF, while the sponsor does what they are best at, and that is providing funding for the actual meeting. David Kessens PS it will also be easier to deal with complaints: no cookies at the break ? well, maybe you or employer should have sponsored the break then. --- On Thu, Mar 23, 2006 at 07:34:00PM -0800, Andy Bierman wrote: Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Let me rephrase it for a better understanding: I agree that some kind of confidentiality in the negotiation is required, but the common starting point for the overall sponsorship cost should be openly well-known. I think this thread has demonstrated the general ignorance about the real costs, which in turn, doesn't help to take a good decision about the right model to follow. The confidentiality is needed mainly because small sponsorship variations due to local specifics. Moreover, is ridiculous to keep the process secret when people who may be involved or informed about the negotiation being part of IETF bodies, and should keep the confidentiality about that, may be spreading rumors before they are facts. I also agree with you, I'm very concerned and noticed this very recently, about the lack of openness in IETF protocol development, which seem to turn into secret negotiations and long-time planned WG guidance. Regards, Jordi PS: I may be wrong, but I think that I know slightly more about meeting logistics and negotiation than probably the average protocol engineer, having organized entirely myself 3 events for up to 800 people, some others for about half that people, and participated in all the details for a 3500+ event, in addition to several international exhibitions. I'm missing an IETF itself though :-(. De: Keith Moore moore@cs.utk.edu Responder a: [EMAIL PROTECTED] Fecha: Fri, 24 Mar 2006 00:48:11 -0500 Para: [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Making IETF happening in different regions It will also be a more open process. Today, in my opinion, having to negotiate with each possible sponsor in secret, is a broken concept, and against our openness. I'm a lot more concerned about openness in IETF protocol development. some kinds of negotiations really do need to be done in secret. IMHO, having protocol engineers who know next to nothing about meeting logistics try to dictate such terms is a broken concept. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
I second Harald's comment. It has been fantastic in general, congratulations ! Before coming to Dallas, I decided to buy the a/b/g USB dongle for my Mac from Zyxel, which was posted on this list, however the driver has a bug and doesn't support IPv6. Unfortunately the support seems to be terrible as they didn't reacted to any of my emails. But as most of the people seems that were using a anyway, I still used during all the meeting my b/g internal interface and only noticed what Ken indicated below a few times, disturbing but acceptable. I also noticed that IPv6 disappeared from the network and reported it to the NOC. I think they figured out the problem at least in one of the APs or whatever it was. I've requested to know the reason but got no information at the time being. A report with all this info will be extremely useful for sure ! Regards, Jordi De: Ken Raeburn [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 23 Mar 2006 23:35:13 -0600 Para: ietf Mailing List ietf@ietf.org Asunto: Re: An absolutely fantastic wireless IETF On Mar 23, 2006, at 21:58, Harald Alvestrand wrote: Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Mmm... well, my laptop (Mac Powerbook) fell off the b/g network several times, mostly during plenary sessions, but the problems were brief, and I usually had no trouble getting back on. It wasn't perfect, but very much improved over previous meetings. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration' to Historic
The IESG has approved the following document: - 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration ' draft-jones-avt-audio-t38-05.txt as a Historic This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-05.txt This document was Last Called as Proposed Standard in the past, but review by the Audio Video Transport Working Group and the IESG led to concern that the format not become a precedent for future media types. The specification should be published and available for registration, and the media-type should be registered, but only because these are required for a very specific application within ITU SG 16's T.38's real-time fax support. This application is described in the document as a legacy. The Historic designation does not imply that the legacy application should not be operative with this specification and registration to support it, but only that there not be *future* designs, non-legacies, based on this precedent. The media type was sent for review on the ietf-types list recently, referencing RFC 3550 and RFC 4288 (the new media type registration rules) and no issues were raised. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MIME type registration for RTP Payload format for H.224' to Proposed Standard
The IESG has approved the following document: - 'MIME type registration for RTP Payload format for H.224 ' draft-ietf-avt-mime-h224-05.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mime-h224-05.txt-05.txt Technical Summary This memo specifies the Media Type (application/H224) used in for example SDP to negotiate the usage of ITU H.224. H.224 includes a far end camera control protocol which is of primary interest for usage by H.224. Procedures for negotiating both uni- and bi-directional sessions in SDP Offer/Answer are specified. Working Group Summary There is consensus in the WG to publish this document. Protocol Quality This document was reviewed the AVT WG. Key revisions clarified the applicability to be primarily H.224, because this does not support far-end camera control in arbitrary Internet environments. The media type was sent for review to the ietf-types list in message: http://www.alvestrand.no/pipermail/ietf-types/2006-February/001653.html and raised no issues. Magnus Westerlund is the WG Chair shepherd. Allison Mankin is the Responsible Area Director. Note to the RFC Editor Abstract Replace the interesting word conversional with conversational ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'SDP Descriptors for FLUTE' to Experimental RFC
The IESG has approved the following document: - 'SDP Descriptors for FLUTE ' draft-mehta-rmt-flute-sdp-05.txt as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-05.txt This specification was not chartered by either the MMUSIC or RMT working groups because it fits between both, and being an Experimental document, like any reliable multicast document in the Transport Area, it was deemed that it could be worked on most effectively by having targeted reviews by SDP and RMT experts coordinated by the area director. The reviewers were Joerg Ott (MMUSIC Co-Chair), Lorenzo Vicisano (RMT Chair), and Magnus Westerlund (AVT Co-Chair). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The Intrusion Detection Message Exchange Format' to Experimental RFC
The IESG has approved the following document: - 'The Intrusion Detection Message Exchange Format ' draft-ietf-idwg-idmef-xml-16.txt as an Experimental RFC This document is the product of the Intrusion Detection Exchange Format Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt Technical Summary Different elements of intrusion detection systems (IDS) need to communicate with each other. This document defines a standard data model, and implements it as an XML DTD. Working Group Summary There were no major issues during the original approval of this document. However the working group lost momentum addressing IESG comments. By the time the document was next reviewed there was not enough of a working group to form an informed consensus. So this document is being advanced as an experimental submission rather than proposed standard. Protocol Quality This document was reviewed for the IESG by Steve Bellovin. IESG Note The content of this RFC was at one time considered by the IETF, but the working group concluded before this work was approved as a standards-track protocol. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The IESG has chosen to publish this document in order to document the work as it was when the working group concluded and to encourage experimentation and development of the technology. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks' to Proposed Standard
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG to consider the following document: - 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks ' draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Management Information Base for the Session Initiation Protocol (SIP) ' draft-ietf-sip-mib-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce