On firewall traversal vs. bypass
Continuing on something heard at the technical plenary last week. There were people complaining that while protocols like STUN/TURN and ICE are traversing NAT, they are in fact bypassing firewall policies, which they should not be doing. I think it should be noted that ICE [1] does *not* circumvent the typical firewall policies. The default policy of a stateful firewall tends to be keep unsolicited traffic out. Now, the problem is that applications like VoIP or video chats generally follow this policy in theory -- after all, a VoIP call, if accepted, is solicited traffic -- but they do not follow it in practice. Specifically, the media sessions can't punch the necessary holes into stateful firewalls, and just generally are poor at managing the transport flows they use (for instance, checking whether a certain flow actually works before attempting to use it). ICE remedies this, by modifying the on-the-wire behavior of these application protocols so that they match not only the intent but also the letter of the stateful firewall policy. Whether this happens as a side-effect of an ICE-like procedure, or via explicit firewall control is a matter of taste, but we also have to keep in mind that the deployment models for these differ considerably. While the first only requires changes to endpoints, the latter requires ubiquitous deployment to middleboxes to become a *full* solution to the problem. Needless to say, I opt for the first, and consider the latter an optimization. Cheers, Aki [1] http://tools.ietf.org/id/draft-ietf-mmusic-ice ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: about RSVP : Admin hello disable.
Hi, This is a question you might want to take to the CCAMP and MPLS mailing lists. You might also ask the authors of the original I-D. The draft you reference expired almost three years ago. I have seen no mention of this behavior in any subsequent I-D or RFC. Cheers, Adrian - Original Message - From: shivakumar [EMAIL PROTECTED] To: Ietf@ietf.org Sent: Tuesday, July 31, 2007 3:13 AM Subject: about RSVP : Admin hello disable. Whener RSVP hello session is removed , is it necessary to Add Admin object (class 196, Ctype 1) to Hello message? I have came across a draft draft-ali-ccamp-rsvp-hello-gr-admin-00 , which mentions about adding such object ,but the draft is obsolete now. ;)..The philosophy of one century is the common sense of the next. ___ 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: Do you want to have more meetings outside US ?
The meeting fee is almost the single largest monetary expense for me, and it keeps going up. As an individual non-attendee, I couldn't agree more. Even though the December meeting is (literally) on my doorstep, there is no way I can justify $750 just to attend a pair of WG meetings. Well, the fee charged would appear to be directly correlated to the number of people attending. That is, because the IETF must cover its costs not just for the meetings but also for the rest of the year, a good proportion of the cost is independent of the meetings and so must increase per capita as the number of attendees decreases. But wait! There is also a direct correlation between the number of people attending and the cost. That is, the cost is a direct deterrent. Economists out there will recognise this problem, and will understand where the spiral is headed. The choice and cost of location can compound the problem, and it seems to me that one of the main objectives of setting meeting venues (both geography and hotel) must be to increase attendance and so to increase revenue. Adrian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Adrian Farrel writes: Well, the fee charged would appear to be directly correlated to the number of people attending. That is, because the IETF must cover its costs not just for the meetings but also for the rest of the year, a good proportion of the cost is independent of the meetings and so must increase per capita as the number of attendees decreases. But wait! There is also a direct correlation between the number of people attending and the cost. That is, the cost is a direct deterrent. But the two costs aren't the same... The deterrent is the sum of the IETF charge, the hotel charge, the cost of food, liquid refreshment and so on, travel, getting a visa, and finally the cost of being away from one's desk. Economists out there will recognise this problem, and will understand where the spiral is headed. The choice and cost of location can compound the problem, and it seems to me that one of the main objectives of setting meeting venues (both geography and hotel) must be to increase attendance and so to increase revenue. Decreasing the IETF meeting attendees' other costs ought to help: a) make it easier to attend by partially freezing the agenda early. If the secretariat could say from now on only times can change, not days early, that would help. (The WG meetings I care about are in a two-day block almost every time. Just coincidence or good work on part of the secretariat?) b) avoid meeting locations with obnoxious travel or visa issues, or very high costs otherwise. c) try to keep travel short for as many attendees as possible. How sad that there's a conflict between b) and c). Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On firewall traversal vs. bypass
On 7/31/07 4:09 AM, Aki Niemi [EMAIL PROTECTED] wrote: Continuing on something heard at the technical plenary last week. There were people complaining that while protocols like STUN/TURN and ICE are traversing NAT, they are in fact bypassing firewall policies, which they should not be doing. I think it's more complicated than that. 1) there were complaints about the difficulties caused specifically by firewalls (apart from NATs) 2) Eric said that the IETF is producing firewall traversal protocols like ICE 3) I pointed out that ICE is a NAT traversal protocol, not a firewall traversal protocol, and that a key functional difference is that NATs don't really do policy (beyond address policy) while firewalls are specifically policy devices. Where I think we differ is in what we think firewalls ought to do. While the default policy of a residential firewall probably should be something along the lines of keep unsolicited traffic out, enterprise policies tend to be and should be a lot richer. STUN and ICE effectively work by side-effect, creating NAT table mappings simply by passing data across the NAT. In the firewall case you really must allow the firewall the possibility to say no, and you should give the firewall the data it needs to make an informed decision. That data might include application identification, user credentials - whatever information is used as the basis for a policy decision. It's also nice if you're able to tell the application that its request has been denied so that it can fail and/or recover gracefully. I also think the assumption that any media flows across a firewall ought to be allowed is questionable, but that's a somewhat different matter. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Charging I-Ds
One notion might be to charge for publications of Internet Drafts. $500 for a draft name including five revisions and then $25 for each additional revision. The rationale is that it is the draft publications which create work for the entire IETF and the cost of that work should be borne by those who want to see the work accomplished. My understanding was that publishing the IDs today is mainly automatic (at least with the new tools). Charging for publication of IDs will essentially discourage people from doing so, which I think would be a not-so-good effect. In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. In many occasions, I have seen new drafts been announced by the secretariat, but not announced by the authors themselves in the WG they were targeting. In several occasions I emailed such authors to know more about their intention and many times I didn't get any reply at all. The others replied pt-2-pt but never announced their draft on the WG list (but they asked the chairs to do so ;-). So, my conclusion is that in most cases these are students who in their academic standards are required to show evidence of publication. I'm not sure the IETF is designed for this. In the other cases, prospective authors do not understand the IETF process, or are to shy to advertise their work. So, this proposition of charging could be refined as pubishing I-Ds that are not supported by any WG should be charged or something similar. Of course, WG drafts should be free of charge. Note that the aim of this proposition would not to get more fund to the IETF, but to relieve the IETF of the cost of processing drafts that are never read, never discussed, and absolutely useless. Thierry. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
Thierry Ernst wrote: In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. In many occasions, I have seen new drafts been announced by the secretariat, but not announced by the authors themselves in the WG they were targeting. In several occasions I emailed such authors to know more about their intention and many times I didn't get any reply at all. The others replied pt-2-pt but never announced their draft on the WG list (but they asked the chairs to do so ;-). So, my conclusion is that in most cases these are students who in their academic standards are required to show evidence of publication. I'm not sure the IETF is designed for this. In the other cases, prospective authors do not understand the IETF process, or are to shy to advertise their work. So, this proposition of charging could be refined as pubishing I-Ds that are not supported by any WG should be charged or something similar. Of course, WG drafts should be free of charge. Note that the aim of this proposition would not to get more fund to the IETF, but to relieve the IETF of the cost of processing drafts that are never read, never discussed, and absolutely useless. Understood. Let me add one thing I notice over and over again: drafts that do not state where discussion should take place. This really belongs on the front page. Anyway, with the automated submission process, the cost of publishing an ID should be close to zero (not really more than distributing a mail to all mailing list recipients and adding it to the mail archive). Note that even if an ID is never announced or discussed it can still be valuable later on. After all, the author hands over potentially useful IPR to the IETF Trust (unless I'm not mistaken). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
--On Tuesday, 31 July, 2007 01:23 -0400 Jeffrey Altman [EMAIL PROTECTED] wrote: ... In my opinion you want to keep the cost of in person participation down so that there aren't two classes of IETF participants, those who are face-to-face and those who aren't. But we have had that participation model for many, many years, even when the registration fees were zero or trivial. You are part of it and, if you count lost at-office time in figuring out expenses, would probably remain part of it even if the registration fees change: the reality is that relatively few IETF participants are worth less than $600 a week The notion that NomCom eligibility should be determined by those who attend meetings just doesn't make a lot of sense for an organization that prides itself on only making consensus decisions on mailing lists. Instead, we should minimize the challenges to active remote participation and find an alternative source of funds. I wouldn't go so far as doesn't make a lot of sense, although I agree that it is problematic. The difficulty has been, in part, that no one has proposed a better system and, in part, because of an assumption that the meeting-attendees are much more likely to be in touch with personality, skills, and behavior patterns than those who particular purely by mailing list. Of course, the latter assumption becomes more dubious as the community gets larger and the Nomcom members know proportionately fewer people and need to rely more on what they can learn from interviews and questionnaires than on their personal knowledge and experience. One notion might be to charge for publications of Internet Drafts. $500 for a draft name including five revisions and then $25 for each additional revision. The rationale is that it is the draft publications which create work for the entire IETF and the cost of that work should be borne by those who want to see the work accomplished. Of course, this would completely prevent the use of I-Ds to float new ideas and would reduce their utility for documenting alternate positions in a coherent way rather than just poking at the existing drafts on mailing lists. Sometimes drafts are produced for the convenience of the community or to help clarify the issues with a possibly-bad idea, by people who have little financial interest in see[ing] the work accomplished. I think it would be a monumentally bad idea. If we were to do anything along those lines, I'd think about trying to spread the non-meeting overhead costs across the entire participant base, e.g., by making subscriptions to IETF-related mailing lists and access to documents free, but charging a yearly participation fee to anyone who wanted to post anything to any IETF mailing list. I think that is a very bad idea too, but one that is less bad than the I-D one. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Secretariat Services RFP Bidders
IETF Secretariat Services RFP Bidders The IAOC received 6 bids in response to the IETF Secretariat Services RFP: 1. Association Management Solutions 2. ETSI-Forapolis 3. Face to Face Events 4. Hamilton Group Meeting Planners 5. LoBue Majdalany Management Group 6. NeuStar Secretariat Services Bidders seek to perform one or more of the following Secretariat services: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services It is the intent of the IAOC to obtain the best combination of performance and cost for the benefit of the IETF. Accordingly, contracts may be awarded for each of the Secretariat services to separate vendors, to one vendor, or a combination of vendors. The IAOC expects to follow this schedule: August - September: Proposal Evaluation September - October: Contract(s) Negotiation November: Contract(s) Award January 2008: Contract(s) Commence The initial contract term will be for two (2) years, commencing on January 1, 2008, with an option on the part of the parties for a renewal of up to two (2) additional years. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, Jul 31, 2007 at 03:22:58PM +0200, Thierry Ernst [EMAIL PROTECTED] wrote a message of 42 lines which said: Note that the aim of this proposition would not to get more fund to the IETF, but to relieve the IETF of the cost of processing drafts that are never read, never discussed, and absolutely useless. Therefore, I do not understand your proposal. If an I-D is never read and never discussed, its cost is nil, no? (sending it to a mailing list has no real cost). If an I-D is reviewed by several persons in the WG, one AD, two members of IESG, etc, then, yes, it costs money but such an in-depth review does not happen for random student-published I-D. To summary: what problem do we try to solve? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On 7/31/07 10:51 AM, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: If an I-D is reviewed by several persons in the WG, one AD, two members of IESG, etc, then, yes, it costs money but such an in-depth review does not happen for random student-published I-D. There is still no cost to the IETF, since review time is volunteer time. The costs are for the secretariat, since someone has to extract the attachments or retrieve the drafts, get them into the database, keep the systems up and running, etc. That said, I think the idea of charging for draft publication is ghastly. Incentives matter, and structures that encourage more openness are better than structures that discourage more openness. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Peter Saint-Andre [EMAIL PROTECTED] writes: Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? I agree with this. Being away from work (and family) decreases my productivity, and while being present at IETF meetings increases productivity, I don't think the advantages of being present outweighs the disadvantages (productivity-wise) for me. Even further, how about breaking up the IETF into smaller, more agile standards development organizations? We essentially did that with XMPP by using the XMPP Standards Foundation for extensions to XMPP rather than doing all our work at the IETF (given the large number of XMPP extensions, doing all that work at the IETF would have represented a denial of service attack on the Internet Standards Process). I see a few potential benefits here: 1. Greater focus on rough consensus and running code. 2. Fewer bureaucracy headaches. 3. Reduced workload for our stressed-out IESG members. :) Just a thought... I think that is a good idea. The IETF could provide guidelines for self-organizing group efforts, such as mailing list policy, IPR templates, bug tracker, conflict resolution systems, etc, and let people standardize ideas and even experiment with implementations. When such efforts are successful, the technical work can be guided through the IETF process (potentially changing the design to fix problems). I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, Jul 31, 2007 at 04:51:56PM +0200, Stephane Bortzmeyer wrote: To summary: what problem do we try to solve? either reducing ietf costs, or increasing ietf income do we know the 'cost per i-d'? or is that meaningless anyway while the i-d live in the automated part of the process? tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. that's a really amazing statement. If I were participating in a WG whose chair had that attitude, I'd be lobbying hard with the IESG for another chair, as I'd suspect that the incumbent chair was inappropriately hostile to introduction of new ideas within the WG. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
Melinda Shore wrote: On 7/31/07 10:51 AM, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: If an I-D is reviewed by several persons in the WG, one AD, two members of IESG, etc, then, yes, it costs money but such an in-depth review does not happen for random student-published I-D. There is still no cost to the IETF, since review time is volunteer time. The costs are for the secretariat, since someone has to extract the attachments or retrieve the drafts, get them into the database, keep the systems up and running, etc. I-Ds do have a cost to the community as well as to the secretariat. For instance: The more I-Ds there are, the harder it is to find the document you're looking for if you don't know the I-D identifier. And every I-D announcement becomes another interrupt that has to be serviced by people who want to know enough about the I-D to understand whether it is relevant. In order to be really effective in IETF it's important to know about useful new ideas, and also to know which of those ideas are gaining traction within the community. Still, I-Ds exist to allow half-baked ideas to be aired. The notion that it's possible to objectively distinguish useful I-Ds from useless ones is silly. That said, I think the idea of charging for draft publication is ghastly. Incentives matter, and structures that encourage more openness are better than structures that discourage more openness. agree entirely. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Jul 31, 2007, at 11:25 AM, Tim Chown wrote: On Tue, Jul 31, 2007 at 04:51:56PM +0200, Stephane Bortzmeyer wrote: To summary: what problem do we try to solve? either reducing ietf costs, or increasing ietf income do we know the 'cost per i-d'? or is that meaningless anyway while the i-d live in the automated part of the process? Neither running the software nor maintaining it is free (and we get lots of help from some pretty capable volunteers as it is). Regards Marshall tim ___ 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: IPv6: Do you want to have more meetings outside US ?
On 30-Jul-2007, at 10:24, Brian E Carpenter wrote: On 2007-07-30 07:05, Tony Li wrote: On Jul 29, 2007, at 8:39 AM, Peter Dambier wrote: Is there any IPv6 activity inside the US? Some. NTT/America, for example, is a Tier 1 provider with v6 deployed. Comcast (cable-based ISP) is rumored to be working on v6. Not to mention every supplier to the US Government. I've actually tried to buy v6 service from carriers who presumably claim to provide it for the very reasons you allude to. It's very hard to buy it if you're just a normal customer (at least, that was my experience). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
Keith Moore [EMAIL PROTECTED] wrote: In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. that's a really amazing statement. If I were participating in a WG whose chair had that attitude, I'd be lobbying hard with the IESG for another chair, as I'd suspect that the incumbent chair was inappropriately hostile to introduction of new ideas within the WG. Sorry, what attitude are you talking about here ? I was speaking about people who publish drafts but never say a word to anyone about their draft. What's the purpose ? If the purpose is to get new ideas through, I don't see how publishing a draft and non advertising is useful for the sender (it may for the reader). But more importantly, I don't see what you see as hostile in the observation above. Thierry. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6: Do you want to have more meetings outside US ?
On 30-Jul-2007, at 01:05, Tony Li wrote: On Jul 29, 2007, at 8:39 AM, Peter Dambier wrote: Is there any IPv6 activity inside the US? Some. NTT/America, for example, is a Tier 1 provider with v6 deployed. Also Global Crossing and Teleglobe/VSNL International. There are also European providers who can do a native v6 handoff that sell transit in North America (e.g. CW, Tiscali). In the scheme of things this is still a pretty small set, but it's not empty. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Do you want to have more meetings outside US ?
The day on which virtual meetings are as productive as face to face will be the day when the IETF has completed its purpose and is no longer necessary. I do far less work in the meetings than I do in the hallways. Face to Face still matters. From: Simon Josefsson [mailto:[EMAIL PROTECTED] Sent: Tue 31/07/2007 11:22 AM To: Peter Saint-Andre Cc: ietf@ietf.org Subject: Re: Do you want to have more meetings outside US ? Peter Saint-Andre [EMAIL PROTECTED] writes: Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? I agree with this. Being away from work (and family) decreases my productivity, and while being present at IETF meetings increases productivity, I don't think the advantages of being present outweighs the disadvantages (productivity-wise) for me. Even further, how about breaking up the IETF into smaller, more agile standards development organizations? We essentially did that with XMPP by using the XMPP Standards Foundation for extensions to XMPP rather than doing all our work at the IETF (given the large number of XMPP extensions, doing all that work at the IETF would have represented a denial of service attack on the Internet Standards Process). I see a few potential benefits here: 1. Greater focus on rough consensus and running code. 2. Fewer bureaucracy headaches. 3. Reduced workload for our stressed-out IESG members. :) Just a thought... I think that is a good idea. The IETF could provide guidelines for self-organizing group efforts, such as mailing list policy, IPR templates, bug tracker, conflict resolution systems, etc, and let people standardize ideas and even experiment with implementations. When such efforts are successful, the technical work can be guided through the IETF process (potentially changing the design to fix problems). I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. /Simon ___ 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: Charging I-Ds
Thierry Ernst wrote: Keith Moore [EMAIL PROTECTED] wrote: In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. that's a really amazing statement. If I were participating in a WG whose chair had that attitude, I'd be lobbying hard with the IESG for another chair, as I'd suspect that the incumbent chair was inappropriately hostile to introduction of new ideas within the WG. Sorry, what attitude are you talking about here ? I was speaking about people who publish drafts but never say a word to anyone about their draft. What's the purpose ? it used to be the case that merely publishing a draft would get some attention for it. these days, that amount of attention is probably very small. also, publishing an I-D might be useful for other reasons - e.g. to establish prior art in case an idea or invention in the draft is ever patented by someone else. and how do you know that the authors never say a word to anyone about their draft? If the purpose is to get new ideas through, I don't see how publishing a draft and non advertising is useful for the sender (it may for the reader). But more importantly, I don't see what you see as hostile in the observation above. perhaps I misunderstood. I just don't want to further raise the barrier for publishing I-Ds, because it's easier for the community to deal with ideas published in that form than, say, on a web page or blog. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Charging I-Ds
Its a nonsense idea. The vanity press formerly known as peer-reviewed journals have become virtually irrelevant for any purpose other than determining academic tenure or award of research grants. If its not on the Web it is not going to influence anyone else. Charges that bear no relationship to the underlying costs are a nonsense that will simply not fly. Publication fees in academic publishing are a racket on top of a racket that is not going to last long. Charging $5 to publish a document on the Web is not going to fly, still less $500. Google will give you a blog for free and you can be pretty certain it will be arround in a century or so. An internet draft is expired and deleted in 6 months. If the cost of publication is a burden to the secretariat we need to look at ways to reduce the cost. XML2RFC makes it much easier to move towards automated publication. From: Thierry Ernst [mailto:[EMAIL PROTECTED] Sent: Tue 31/07/2007 9:22 AM To: ietf@ietf.org Subject: Charging I-Ds One notion might be to charge for publications of Internet Drafts. $500 for a draft name including five revisions and then $25 for each additional revision. The rationale is that it is the draft publications which create work for the entire IETF and the cost of that work should be borne by those who want to see the work accomplished. My understanding was that publishing the IDs today is mainly automatic (at least with the new tools). Charging for publication of IDs will essentially discourage people from doing so, which I think would be a not-so-good effect. In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. In many occasions, I have seen new drafts been announced by the secretariat, but not announced by the authors themselves in the WG they were targeting. In several occasions I emailed such authors to know more about their intention and many times I didn't get any reply at all. The others replied pt-2-pt but never announced their draft on the WG list (but they asked the chairs to do so ;-). So, my conclusion is that in most cases these are students who in their academic standards are required to show evidence of publication. I'm not sure the IETF is designed for this. In the other cases, prospective authors do not understand the IETF process, or are to shy to advertise their work. So, this proposition of charging could be refined as pubishing I-Ds that are not supported by any WG should be charged or something similar. Of course, WG drafts should be free of charge. Note that the aim of this proposition would not to get more fund to the IETF, but to relieve the IETF of the cost of processing drafts that are never read, never discussed, and absolutely useless. Thierry. ___ 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: Charging I-Ds
Keith Moore [EMAIL PROTECTED] wrote: In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. that's a really amazing statement. If I were participating in a WG whose chair had that attitude, I'd be lobbying hard with the IESG for another chair, as I'd suspect that the incumbent chair was inappropriately hostile to introduction of new ideas within the WG. Sorry, what attitude are you talking about here ? I was speaking about people who publish drafts but never say a word to anyone about their draft. Please explain how it is you can be sure they haven't communicated to anyone about their draft. What's the purpose ? People are, as a rule, lazy. It is therefore pretty unlikely that they will engage in a fairly time-consuming activity with no purpose in mind. A better question is whether or not the purpose for which some drafts are published is in line with the general goals of the IETF, and if it isn't should something be done about it. For example, I suspect that in some cases drafts are published primarily for the authors to be able say that they have done work in the IETF. So let's suppose, for the sake of argument, that (a) The cost of publishing an I-D is significant, (b) Lots of drafts are published that aren't intended to fulfill the goals of the IETF. Given these assumptions the obvious fix is to reduce publication costs with better automation. I find it extremely hard to believe that our publication needs cannot be met with an almost entirely automated system, one where the per-draft costs are extremely low. We might have to sacrifice a little to make it work, but given that we're a bunch of engineers here and engineering is always about tradeoffs I see no reason why we should be unwilling or unable to apply engineering principles to our internal processes. For example, if extraction of drafts from email cannot be automated I think we all could survive with a web-based submission tool. But even if we cannot get the costs down I don't think charging for being able to post a draft solves the problem. Rather, the likely outcomes is that people will simply stop posting drafts to a central server. They will instead post their drafts to their own servers and send a message to one or more IETF lists saying they have done so. So this won't work unless we accompany the charge with a hard rule that only drafts posted to the authorized IETF server can be discussed on IETF lists, and at that point I suspect we'd have a full scale revolt on our hands. (To be perfectly honest I'd likely be one of the people leading the revolt.) If the purpose is to get new ideas through, I don't see how publishing a draft and non advertising is useful for the sender (it may for the reader). But more importantly, I don't see what you see as hostile in the observation above. Your saying that your experience as a working group chair is what led you to this conclusion is what made it hostile - very hostile indeed IMO. It would have read very differently had you instead made the comment speaking as a general IETF participant. But given the context Keith's characterization sounded spot on to me. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, 31 Jul 2007 12:29:51 -0400 Keith Moore [EMAIL PROTECTED] wrote: Thierry Ernst wrote: Keith Moore [EMAIL PROTECTED] wrote: In principle I would be against charging, but my experience of being a chair makes me believe that many authors have no reason to publish their I-D which are just a burden to the I-D secretariat and thus the entire IETF community. that's a really amazing statement. If I were participating in a WG whose chair had that attitude, I'd be lobbying hard with the IESG for another chair, as I'd suspect that the incumbent chair was inappropriately hostile to introduction of new ideas within the WG. Sorry, what attitude are you talking about here ? I was speaking about people who publish drafts but never say a word to anyone about their draft. What's the purpose ? it used to be the case that merely publishing a draft would get some attention for it. these days, that amount of attention is probably very small. also, publishing an I-D might be useful for other reasons - e.g. to establish prior art in case an idea or invention in the draft is ever patented by someone else. OK, this may be a valid reason (though I doubt the IETF process of publishing I-D has been designed for such a reason). and how do you know that the authors never say a word to anyone about their draft? Well, I meant the WG doesn't know, but individuals who monitor [EMAIL PROTECTED] may. I just wonder why as an author I would take my time to write a draft which deal with protocol ABCD and not announce it on the ABCD mailing list. To me this is non sense, and my interpretation is that the intend is not to inform ABCD but to get the document published (with no reviews). I'm working in the academic world and I've seen many claims of documents published to the IETF, in some universities it could be perceived as an international publication or as being discussed within the IETF while it's not. If the purpose is to get new ideas through, I don't see how publishing a draft and non advertising is useful for the sender (it may for the reader). But more importantly, I don't see what you see as hostile in the observation above. perhaps I misunderstood. I just don't want to further raise the barrier for publishing I-Ds, because it's easier for the community to deal with ideas published in that form than, say, on a web page or blog. This I agree, as for establishing prior art. Anyway, your comment would have been more productive if you had said so in the first place rather than accusing chairs of hostility (with no obvious reason). Thierry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
Tim Chown wrote: On Tue, Jul 31, 2007 at 04:51:56PM +0200, Stephane Bortzmeyer wrote: To summary: what problem do we try to solve? either reducing ietf costs, or increasing ietf income do we know the 'cost per i-d'? or is that meaningless anyway while the i-d live in the automated part of the process? Expected result of charging per I-D: bigger I-Ds. /psa -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6: Do you want to have more meetings outside US ?
We try to keep an updated list of services at http://www.ipv6-to-standard.org Type isp at the free search. Regards, Jordi De: Joe Abley [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 31 Jul 2007 12:19:33 -0400 Para: Brian E Carpenter [EMAIL PROTECTED] CC: Tony Li [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: IPv6: Do you want to have more meetings outside US ? On 30-Jul-2007, at 10:24, Brian E Carpenter wrote: On 2007-07-30 07:05, Tony Li wrote: On Jul 29, 2007, at 8:39 AM, Peter Dambier wrote: Is there any IPv6 activity inside the US? Some. NTT/America, for example, is a Tier 1 provider with v6 deployed. Comcast (cable-based ISP) is rumored to be working on v6. Not to mention every supplier to the US Government. I've actually tried to buy v6 service from carriers who presumably claim to provide it for the very reasons you allude to. It's very hard to buy it if you're just a normal customer (at least, that was my experience). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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: Charging I-Ds
On 7/31/07 1:01 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Expected result of charging per I-D: bigger I-Ds. Library science research in the early 1980s found that the number of authors was highly correlated with title length, so one might reasonably expect that charging for internet draft publication might result in longer draft titles. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Charging I-Ds
Melinda, I was trying to avoid weighing in on this discussion. The discussion is essentially inane, and that's (at least part of) your point. After all, the thought that someone might be asked to work on an ID, and then - in addition to volunteering their time to do the work - they then need to pay (per iteration) for the privilege of submitting it is utterly absurd. The whole idea of taxing volunteers is, as you said, ghastly. But - while we're on the subject of volunteering - your comment that reviews are at no cost to the IETF isn't quite correct. As a well-known SciFi author used to say - there ain't no such thing as a free lunch - (or TANSTAAFL). The effort to find sufficient volunteers to review documents is not a no cost exercise. -- Eric Gray Principal Engineer Ericsson -Original Message- From: Melinda Shore [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 11:02 AM To: Stephane Bortzmeyer; Thierry Ernst Cc: ietf@ietf.org Subject: Re: Charging I-Ds On 7/31/07 10:51 AM, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: If an I-D is reviewed by several persons in the WG, one AD, two members of IESG, etc, then, yes, it costs money but such an in-depth review does not happen for random student-published I-D. There is still no cost to the IETF, since review time is volunteer time. The costs are for the secretariat, since someone has to extract the attachments or retrieve the drafts, get them into the database, keep the systems up and running, etc. That said, I think the idea of charging for draft publication is ghastly. Incentives matter, and structures that encourage more openness are better than structures that discourage more openness. Melinda ___ 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: Charging I-Ds
There is still no cost to the IETF, since review time is volunteer time. The costs are for the secretariat, since someone has to extract the attachments or retrieve the drafts, get them into the database, keep the systems up and running, etc. And, with the advent of the online I-D submission tool (coming soon?) this will be reduced somewhat. In fact, since we want to encourage the propagation of ideas and the development of new standards, should the IETF be paying for every I-D that is published? This would tie in with the $200 that WG chairs get for every RFC that their working group produces. Adrian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Tue, Jul 31, 2007 at 12:29:51PM -0400, Keith Moore wrote: also, publishing an I-D might be useful for other reasons - e.g. to establish prior art in case an idea or invention in the draft is ever patented by someone else. I have written or co-written a few drafts in the past purely as problem statements or to raise issues. Rather than repeat text in list discussions, it's 'nice' to have a plain text format statement of an #issue or problem to focus discussion. While the draft may become an RFC, it also quite commonly may not if the solution draft briefly cpatures the issue at hand. Sure, the statement could be a web page, but the IETF 'version control' on texts is also quite handy to see how a text evolved over time. tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
Melinda Shore wrote: On 7/31/07 1:01 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Expected result of charging per I-D: bigger I-Ds. Library science research in the early 1980s found that the number of authors was highly correlated with title length, so one might reasonably expect that charging for internet draft publication might result in longer draft titles. You mean someone might break my record? http://tools.ietf.org/html/draft-saintandre-xmpp-simple /psa -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [OT] Internet / DNS Timeline (The History of the Internet DNS)
On Thu, Jul 19, 2007 at 10:10:28AM -0400, Joe Baptista [EMAIL PROTECTED] wrote: Now this is an interesting little giggle. I made it into a DNS timeline. Incredible. http://www.inaic.com/index.php?p=internet-dns-timeline ... a timeline of the DNS that documents the teeniest details, but leaves out the edu.com disaster? Huh. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: On firewall traversal vs. bypass
-Original Message- From: Aki Niemi [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 1:10 AM To: ietf@ietf.org Subject: On firewall traversal vs. bypass Continuing on something heard at the technical plenary last week. There were people complaining that while protocols like STUN/TURN and ICE are traversing NAT, they are in fact bypassing firewall policies, which they should not be doing. I think it should be noted that ICE [1] does *not* circumvent the typical firewall policies. The default policy of a stateful firewall tends to be keep unsolicited traffic out. Now, the problem is that applications like VoIP or video chats generally follow this policy in theory -- after all, a VoIP call, if accepted, is solicited traffic -- but they do not follow it in practice. Specifically, the media sessions can't punch the necessary holes into stateful firewalls, and just generally are poor at managing the transport flows they use (for instance, checking whether a certain flow actually works before attempting to use it). ICE remedies this, by modifying the on-the-wire behavior of these application protocols so that they match not only the intent but also the letter of the stateful firewall policy. Whether this happens as a side-effect of an ICE-like procedure, or via explicit firewall control is a matter of taste, but we also have to keep in mind that the deployment models for these differ considerably. While the first only requires changes to endpoints, the latter requires ubiquitous deployment to middleboxes to become a *full* solution to the problem. Needless to say, I opt for the first, and consider the latter an optimization. Here is one way to do the first, http://tools.ietf.org/id/draft-wing-session-auth-00.txt (currently expired). -d Cheers, Aki [1] http://tools.ietf.org/id/draft-ietf-mmusic-ice ___ 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
Funding (was Re: Charging I-Ds)
Charging for IDs will kill innovation. I use IDs to float ideas which
may or may not bear fruition. I would not work on these if I had to pay.
I also work on things at the IETF than my employer does not sponsor.
These things will get thrown out as well.
Since we have started slaughtering the sacred cows (free {ids,mailing
lists, rfcs ...}), I might as well suggest few more.
* Make remote participants share the costs. i.e. charge for live
audio/video feeds. I believe this is fairer than charging for ids, rfcs
or mailing lists. People who want to participate, but are unable to
travel can get these for a lower meeting fee (25% maybe).
* Get some kind of corporate sponsorships for supporting free documents
(kind of like IEEE get 802)
* Cut back on the food and beverages
I would be unhappy with some of these things, but at least they still
retain the openness of the IETF and are reasonably fair.
Cheers
Suresh
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
perhaps I misunderstood. I just don't want to further raise the barrier for publishing I-Ds, because it's easier for the community to deal with ideas published in that form than, say, on a web page or blog. This I agree, as for establishing prior art. Anyway, your comment would have been more productive if you had said so in the first place rather than accusing chairs of hostility (with no obvious reason). I don't know you or your WG, so it wasn't a comment about you. I'm perhaps biased from having seen a few WG chairs who railroaded half-baked proposals through their groups and were hostile to input that contradicted their agendas. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Peter Saint-Andre wrote: Matt Pounsett wrote: for the two or three wg meetings I'm interested in, there's little point in me being at the meeting for a whole week. What about holding two or three meetings smaller meetings a year for each area, and then just one big meeting for the full IETF? That would bring down the cost of the individual area meetings and therefore the admission fee, make them smaller and therefore capable of fitting into a wider range of hotels, and would likely result in fewer nights of hotel stay for a lot of people. Depends on how much overlap there is for attendees. How many people want to attend meetings in both (say) security and applications, I am certainly in this group. I don't think I am alone ;-). or transport and RAI? This is an empirical question that could be answered through surveys. Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? I am in favor of this, but I don't think this can replace many ad-hoc meetings on yet-non-specified topics that happen all the time during IETF meetings. Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? As long as the number of face-to-face meetings is not 0, this might be something to think about. Even further, how about breaking up the IETF into smaller, more agile standards development organizations? We essentially did that with XMPP by using the XMPP Standards Foundation for extensions to XMPP rather than doing all our work at the IETF (given the large number of XMPP extensions, doing all that work at the IETF would have represented a denial of service attack on the Internet Standards Process). I see a few potential benefits here: 1. Greater focus on rough consensus and running code. 2. Fewer bureaucracy headaches. 3. Reduced workload for our stressed-out IESG members. :) + Less cross area review. I would rather you try to standardize XMPP extensions in IETF and see if this would actually cause any DoS. (Well, maybe not all of them. Some XMPP extensions should probably die inside XSF ;-)) Just a thought... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Secretariat Services RFP Bidders
On 7/31/07 at 10:32 AM -0400, IETF Administrative Director wrote: The IAOC received 6 bids in response to the IETF Secretariat Services RFP: 1. Association Management Solutions 2. ETSI-Forapolis 3. Face to Face Events 4. Hamilton Group Meeting Planners 5. LoBue Majdalany Management Group 6. NeuStar Secretariat Services Bidders seek to perform one or more of the following Secretariat services: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services Can you say which of the 6 bidders bid for which of the 3 services? pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Simon Josefsson wrote: Peter Saint-Andre [EMAIL PROTECTED] writes: Even further, how about breaking up the IETF into smaller, more agile standards development organizations? We essentially did that with XMPP by using the XMPP Standards Foundation for extensions to XMPP rather than doing all our work at the IETF (given the large number of XMPP extensions, doing all that work at the IETF would have represented a denial of service attack on the Internet Standards Process). I see a few potential benefits here: 1. Greater focus on rough consensus and running code. 2. Fewer bureaucracy headaches. 3. Reduced workload for our stressed-out IESG members. :) Just a thought... I think that is a good idea. The IETF could provide guidelines for self-organizing group efforts, such as mailing list policy, IPR templates, bug tracker, conflict resolution systems, etc, and let people standardize ideas and even experiment with implementations. When such efforts are successful, the technical work can be guided through the IETF process (potentially changing the design to fix problems). The danger here is that when people bring work to IETF, they might refuse to change protocols which are already deployed. And speaking of cross area review again: last thing I want is to be forced to go to multiple smaller meetings in various other organizations instead of attending 3 IETF meetings per-year. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Cyrus Daboo wrote: Hi Peter, --On July 30, 2007 2:11:38 PM -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? All that will do is shift the discussion from where shall we hold the meeting to what time/timezone shall we have for our conf call. Given that we have people participating from across the globe, trying to arrange a time that is acceptable for all participants will be just as hard as trying to find a meeting venue acceptable to all. You can hold multiple meetings at different times. Not ideal, but there has to be a better way to get all interested parties in a discussion at the same time than forcing them to burn jet fuel. I'm not opposed to in-person meetings -- there's nothing like a good Bar BOF. I just think that we could more productively leverage the real-time collaboration technologies we've developed to make progress between IRL meetings, and perhaps run more focused IRL meetings as a result. Unfortunately we don't have scheduling tools that will help resolve issues like that (or at least make it easier than a multiple party email exchange/negotiation) - but some of us are working on that! Keep up the good work! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Secretariat Services RFP Bidders
Pete Resnick wrote: On 7/31/07 at 10:32 AM -0400, IETF Administrative Director wrote: The IAOC received 6 bids in response to the IETF Secretariat Services RFP: 1. Association Management Solutions 2. ETSI-Forapolis 3. Face to Face Events 4. Hamilton Group Meeting Planners 5. LoBue Majdalany Management Group 6. NeuStar Secretariat Services Bidders seek to perform one or more of the following Secretariat services: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services Can you say which of the 6 bidders bid for which of the 3 services? The RFP said the names of all the Offerors would be announced on 31 July, but did not specify that the services for which they were bidding would be revealed. Accordingly, I am reluctant to provide greater detail. Ray pr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
on the value of running code (was Re: Do you want to have more meetings outside US ?)
The danger here is that when people bring work to IETF, they might refuse to change protocols which are already deployed. This already happens to far too great a degree. People keep arguing that because they have running/deployed code, IETF has to standardize exactly what they have already produced. In many cases things that are deployed before they get widespread design review are very poorly designed. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). IMHO, running code gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. running code was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
DHCP failures (was RE: Do you want to have more meetings outside US ?)
JORDI PALET MARTINEZ wrote: ... The poor network infrastructure is not only a question of the links. It is a question of having a good or bad network, like the problem that we had all this week with the DHCP. Having a good link the network was still unusable 60% of the time. I had no problem at all because the IPv6 path didn't rely on the failing DHCP service. ;) That said, several of us did notice that the local DNS servers did not have any records, so likely they did not have any IPv6 configured either. Even if they did, we would need to finalize the work to put the DNS address in the RA to completely avoid the need for DHCP for those that rely on local configuration. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
On Aug 1, 2007, at 12:40 AM, Tony Hain wrote: JORDI PALET MARTINEZ wrote: ... The poor network infrastructure is not only a question of the links. It is a question of having a good or bad network, like the problem that we had all this week with the DHCP. Having a good link the network was still unusable 60% of the time. I had no problem at all because the IPv6 path didn't rely on the failing DHCP service. ;) That said, several of us did notice that the local DNS servers did not have any records, so likely they did not have any IPv6 configured either. Even if they did, we would need to finalize the work to put the DNS address in the RA to completely avoid the need for DHCP for those that rely on local configuration. thats why i like the bonjour idea;) http://www.dns-sd.org/ServerTestSetup.html marcM. Tony -- Imagination is more important than Knowledge http://www.braustelle.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
--On Tuesday, 31 July, 2007 15:40 -0700 Tony Hain [EMAIL PROTECTED] wrote: JORDI PALET MARTINEZ wrote: ... The poor network infrastructure is not only a question of the links. It is a question of having a good or bad network, like the problem that we had all this week with the DHCP. Having a good link the network was still unusable 60% of the time. I had no problem at all because the IPv6 path didn't rely on the failing DHCP service. ;) ... Almost independent of the IPv6 autoconfig issues, I find it deeply troubling that we seem to be unable to both * get the ducks lined up to run IPv6 fully and smoothly, with and without local/auto config. * get a DHCP arrangement (IPv4 and, for those who want to use it, IPv6) that performs reliably, consistently, and largely invisibly (if I have to worry about what a DHCP server is doing, it isn't working well). and have both of those working seamlessly no later than Sunday afternoon of the meeting. If we can't do that, we should be very seriously reviewing our protocols and specifications: that sort of thing shouldn't be, in any sense, an experiment at this stage. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
On 1-aug-2007, at 0:59, John C Klensin wrote: Almost independent of the IPv6 autoconfig issues, I find it deeply troubling that we seem to be unable to both * get the ducks lined up to run IPv6 fully and smoothly, with and without local/auto config. IPv6 worked pretty well this time, although still ~60 ms (1.5x) slower than IPv4. * get a DHCP arrangement (IPv4 and, for those who want to use it, IPv6) that performs reliably, consistently, and largely invisibly (if I have to worry about what a DHCP server is doing, it isn't working well). A good start would be explaining what exactly went wrong with the DHCP server(s) this time. We have a problem and we're working on it is not all that helpful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
John, Almost independent of the IPv6 autoconfig issues, I find it deeply troubling that we seem to be unable to both * get the ducks lined up to run IPv6 fully and smoothly, with and without local/auto config. * get a DHCP arrangement (IPv4 and, for those who want to use it, IPv6) that performs reliably, consistently, and largely invisibly (if I have to worry about what a DHCP server is doing, it isn't working well). and have both of those working seamlessly no later than Sunday afternoon of the meeting. Agreed. In my case, I found the IPv6 support at IETF69 better than most past IETF meetings. It was also interesting to open the Mac network control pannel, enable my Airport (WLAN) interface, and see the IPv6 global address appear almost instantaneously and in many case having to wait many seconds to minutes for DHCP provided IPv4 address to appear. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Charging I-Ds
The current business model does not bring in enough cash. How do we bring in more in a way that furthers ietf goals? E.g. other standards setting bodies have paid memberships and/or sellable standards. IETF unique way could be to charge a fee for an address allocation to RIRs. On their side RIRs would charge for assignments as they do now and return a fair share back to IANA/IETF. If IETF start charging for reading contributors' papers how much voluntary contribution such arrangement would generate? Is there a guarantee that a pre-paid content remains worth reading? Thanks, Peter --- Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: This is a topic on which everyone can have an opinion, hence many posts. Perhaps if there was a charge per post to an ietf mailing list? There is a serious point here though, Cerf, Postel and co have left us an institution with a 60s flower power era business model and a 1990s expectation of quality of service. The current business model does not bring in enough cash. How do we bring in more in a way that furthers ietf goals? We could adopt the nist model of franchising conformance testing, only with an incremental fee on top paid to the ietf for use of the brand. The fee per item does not have to be very large to bring in a lot of cash. We only need five or so million a year. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Eric Gray (LO/EUS) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 10:43 AM Pacific Standard Time To: Melinda Shore; Stephane Bortzmeyer; Thierry Ernst Cc: ietf@ietf.org Subject: RE: Charging I-Ds Melinda, I was trying to avoid weighing in on this discussion. The discussion is essentially inane, and that's (at least part of) your point. After all, the thought that someone might be asked to work on an ID, and then - in addition to volunteering their time to do the work - they then need to pay (per iteration) for the privilege of submitting it is utterly absurd. The whole idea of taxing volunteers is, as you said, ghastly. But - while we're on the subject of volunteering - your comment that reviews are at no cost to the IETF isn't quite correct. As a well-known SciFi author used to say - there ain't no such thing as a free lunch - (or TANSTAAFL). The effort to find sufficient volunteers to review documents is not a no cost exercise. -- Eric Gray Principal Engineer Ericsson -Original Message- From: Melinda Shore [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 11:02 AM To: Stephane Bortzmeyer; Thierry Ernst Cc: ietf@ietf.org Subject: Re: Charging I-Ds On 7/31/07 10:51 AM, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: If an I-D is reviewed by several persons in the WG, one AD, two members of IESG, etc, then, yes, it costs money but such an in-depth review does not happen for random student-published I-D. There is still no cost to the IETF, since review time is volunteer time. The costs are for the secretariat, since someone has to extract the attachments or retrieve the drafts, get them into the database, keep the systems up and running, etc. That said, I think the idea of charging for draft publication is ghastly. Incentives matter, and structures that encourage more openness are better than structures that discourage more openness. Melinda ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Funding (was Re: Charging I-Ds)
Charging for IDs will kill innovation. I use IDs to float ideas which may or may not bear fruition. I would not work on these if I had to pay. I also work on things at the IETF than my employer does not sponsor. These things will get thrown out as well. I assume i-d to be a proposal for a new protocol, which is implementable with a reasonable efforts and costs. i think your view and my view are opposite. i'd like to see the following: - submission of i-d requires an implementation - to become a RFC requires two independent interoperable implementation itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
--On Wednesday, 01 August, 2007 01:14 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: * get a DHCP arrangement (IPv4 and, for those who want to use it, IPv6) that performs reliably, consistently, and largely invisibly (if I have to worry about what a DHCP server is doing, it isn't working well). A good start would be explaining what exactly went wrong with the DHCP server(s) this time. We have a problem and we're working on it is not all that helpful. While I agree, I also believe that, if that story happens at one meeting, it is a local problem. If it happens at two, we either have a protocol problem (which might be reflected in a problem with equipment that doesn't quite conform, although I don't have any reason to believe that is the case) or a provider problem. If it is a protocol problem, we should know what went wrong and the DHC WG should have their noses pressed into it. If it isn't, we need to not have it again. Ever. And, while I'm picking on DHCP because I personally had more problems with it, I see IPv6 authconfig as being exactly the same issue: we are telling the world that these things work and they should be using them; if we can't make them work for our own meetings... john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of running code (was Re: Do you want to have more meetings outside US ?)
IMHO, running code gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. running code was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. tend to agree. how about multiple interoperable implementations? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Secretariat Services RFP Bidders
IETF Secretariat Services RFP Bidders The IAOC received 6 bids in response to the IETF Secretariat Services RFP: 1. Association Management Solutions 2. ETSI-Forapolis 3. Face to Face Events 4. Hamilton Group Meeting Planners 5. LoBue Majdalany Management Group 6. NeuStar Secretariat Services Bidders seek to perform one or more of the following Secretariat services: 1. Meeting Services 2. Clerical Support Services 3. IT Support Services It is the intent of the IAOC to obtain the best combination of performance and cost for the benefit of the IETF. Accordingly, contracts may be awarded for each of the Secretariat services to separate vendors, to one vendor, or a combination of vendors. The IAOC expects to follow this schedule: August - September: Proposal Evaluation September - October: Contract(s) Negotiation November: Contract(s) Award January 2008: Contract(s) Commence The initial contract term will be for two (2) years, commencing on January 1, 2008, with an option on the part of the parties for a renewal of up to two (2) additional years. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4972 on Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
A new Request for Comments is now available in online RFC libraries. RFC 4972 Title: Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership Author: JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey Status: Standards Track Date: July 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 32044 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ccamp-automesh-04.txt URL:http://www.rfc-editor.org/rfc/rfc4972.txt The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4971 on Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
A new Request for Comments is now available in online RFC libraries. RFC 4971 Title: Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information Author: JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed. Status: Standards Track Date: July 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 9 Characters: 18541 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-isis-caps-07.txt URL:http://www.rfc-editor.org/rfc/rfc4971.txt This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS TRACK] This document is a product of the IS-IS for IP Internets Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
BCP 131 RFC 4961 on Symmetric RTP / RTP Control Protocol (RTCP)
A new Request for Comments is now available in online RFC libraries. BCP 131 RFC 4961 Title: Symmetric RTP / RTP Control Protocol (RTCP) Author: D. Wing Status: Best Current Practice Date: July 2007 Mailbox:[EMAIL PROTECTED] Pages: 6 Characters: 12539 Updates: See-Also: BCP0131 I-D Tag:draft-wing-behave-symmetric-rtprtcp-03.txt URL:http://www.rfc-editor.org/rfc/rfc4961.txt This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called symmetric RTP and symmetric RTCP. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4970 on Extensions to OSPF for Advertising Optional Router Capabilities
A new Request for Comments is now available in online RFC libraries. RFC 4970 Title: Extensions to OSPF for Advertising Optional Router Capabilities Author: A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer Status: Standards Track Date: July 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 13 Characters: 26416 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ospf-cap-11.txt URL:http://www.rfc-editor.org/rfc/rfc4970.txt It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
