Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin [EMAIL PROTECTED] wrote: I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. +1 Greetings, Norbert. -- Norbert Bollow [EMAIL PROTECTED] http://Norbert.ch President of the Swiss Internet User Group SIUGhttp://SIUG.ch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 29 nov 2007, at 0:18, Paul Hoffman wrote: One easy solution to the problem is to not change anything in the current IETF or RFC rules. If an RFC has been published before the appeal is brought, and that appeal is ultimately successful, a new RFC is issued that obsoletes the old RFC. That new RFC can essentially be a NULL, although hopefully it would have an explanation why an empty RFC is obsoleting a non-empty one. That new RFC can also be partially populated; for example, if the resolution of the appeal is to pull a contentious section or appendix. Given the extreme rarity of the situation where an appeal leads to non-publication or changed publication, it seems wasteful to create new rules (and spend lots of time arguing about them) when no new rules are needed. ++ Especially since presumably, an appealer would be motivated to stop publication of the RFC and file an appeal without delay rather than after 59 days. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
On Wed, Nov 28, 2007 at 11:23:10AM -0600, Pete Resnick [EMAIL PROTECTED] wrote a message of 22 lines which said: It's not geographic balance of places on the world map that people are talking about here. It's geographic balance of places where the people who write IETF documents live. Then, things can go on forever. We do not hold meetings in places where there are not a lot of IETF members. As a result, people from these countries do not come and do not participate. Then, the prophecy becomes true. And so on. If we want to be serious about breaking the vicious circle, we should do meetings in places where there is *currently* few members (I do not suggest Namibia or Papua-New Guinea but, may be, Egypt, Argentina, India, places like that?) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: Whatever people feed into xml2rfc can be made stand-alone by running it once through an XML parser and reserializing; or be applying an identity XSLT transformation. Sure, but my point is people probably don't want to do this all the time. I've got a Makefile for that. Should I share it? But anyway, if you think it doesn't make sense to generate self-contained XML for each I-D, why submit the non-self-contained XML source at all? Obviously you don't submit XML source up until that point. I thought people did and that was a problem. Did I misunderstand something? Yes, you're taking this entire line of commentary completely out of context. This was all in response to Eliot's suggestion that XML versions of the document should be required at the time of WGLC. John K responded to that advising caution for various reasons and I chimed in with the additional reason that this will force people to generate standalone intermediary versions for submission. I'm aware of what started the discussion. However, when I use the submission tool today, I may not even know whether a particular version I submit will be a WGLC version. So I think whatever is the right answer for WGLC or LC is also the right answer for any ID version. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John, I agree with just about everything you say here, except for this: At Thu, 29 Nov 2007 01:56:51 -0500, John C Klensin wrote: And, incidentally, I believe that discussions about inherent conflicts of interest in the current appeals process are irrelevant to this discussion, for two reasons. First, as others have repeatedly pointed out, our appeals mechanisms are an important tool for reaching and establishing consensus, not a judicial procedure. Yes, it's not a judicial procedure, but nevertheless, an appeal of an IESG action inherently involves the claim that the IESG has made a mistake, and the IESG is not exactly in a position to judge that neutrally. Yes, the IESG does sometimes reverse itself, but there have also been times where the IESG has denied an appeal, the appellant has appealled to the IAB, and the IAB has upheld it. Having been involved in such cases, I don't think I would characterize them as establishing consensus. And second, if there are conflicts of interest that we believe are unacceptable, and that belief is based on experience rather than theory or hypothetical situations, then we need to fix 2026 and the appeals process for reasons and in ways that have little to do with the publication delay question. I didn't say that there were COIs that were unacceptable. I said they needed to be mitigated by ensuring that the appellant had an opportunity to have a hearing before a neutral (or as neutral as possible) party. I think the current 2026 procedures more or less do that, but in this particular case there is a bug in the process. It's not one I'd ordinarily spend a lot of time agitating to fix, but since Russ raised the topic of delaying publication, it's worth getting this aspect of it straight. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
John C Klensin [EMAIL PROTECTED] wrote: FWIW, if the enemy is renovations, or even huge and noisy construction projects across the street or in adjacent buildings, a model of going repeatedly to the same venues and building relationships would not help us get more than better-quality sympathy. Hotel behavior is not a coin-toss, even with the same hotel. If there have been no renovation projects for several years in a row, that actually increases the odds that there will be one next time, rather than assuring that there will not be. The point is that if IETF meetings are potentially repeat business for a hotel, that gives the hotel an otherwise-absent strong incentive to do such a good job that we'll want to hold another IETF meeting there. From the hotel's perspective, making sure that we don't get inconvenienced by renovations or other avoidable disruptions would be one aspect of that. Greetings, Norbert. -- Norbert Bollow [EMAIL PROTECTED] http://Norbert.ch President of the Swiss Internet User Group SIUGhttp://SIUG.ch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Eurasia
Maybe I should elaborate. In several WG where I am active at least half of participants are from Europe or Asia. Why do IETF meetings have to be monolithic and all-inclusive? Why can't the IETF hold partial meetings in Europe and Asia? This would probably mean more IETF meetings but nobody has to go to all of them. Essentially, I am suggesting that WGs with a lot of participants in Europe or Asia should be able to band together and hold local IETF meetings leveraging the same IETF secretariat services as the full meetings. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Continental Distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2007, at 8:51 AM, Lars Eggert wrote: Looking at IETF-60 to IETF-70, 8 out of the 10 IETFs were in North America. I'd be good if we could re-balance this in the future. The plan we're working against is at http://ietf.org/meetings/0mtg- sites.txt. The thumbnail sketch of the rule we're following, which I understand to be the current consensus distribution, is that over two years we try to hit North America three times, Europe twice, and Asia once. Does the plan work for you? -BEGIN PGP SIGNATURE- iD8DBQFHTqEabjEdbHIsm0MRAtKsAKCNi56AKWyAp6d4xdtlrnZrrGl1EQCgi3mP wagh82y4sQ9xGRz0wm4Pu5s= =4Hwl -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Eurasia
Maybe I should elaborate. In several WG where I am active at least half of participants are from Europe or Asia. Why do IETF meetings have to be monolithic and all-inclusive? Because there is already a lack of communicaiton between Areas. Not to say that there can't be other smaller meetings as well. Adrian (IETF hotels are too expensive. Book into smaller ones, pay less, and don't get thrown out.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Eurasia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can tell you why we do - crosstalk. It can be incredibly useful for people from the Security Area to look in on Applications, or for Transport and RAI folks to understand the workings of the layers beneath them and their users, for example. That doesn't make for a has to, but it seems like a good reason to choose to, from my perspective. On Nov 29, 2007, at 6:00 AM, [EMAIL PROTECTED] wrote: Maybe I should elaborate. In several WG where I am active at least half of participants are from Europe or Asia. Why do IETF meetings have to be monolithic and all-inclusive? Why can't the IETF hold partial meetings in Europe and Asia? This would probably mean more IETF meetings but nobody has to go to all of them. Essentially, I am suggesting that WGs with a lot of participants in Europe or Asia should be able to band together and hold local IETF meetings leveraging the same IETF secretariat services as the full meetings. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -BEGIN PGP SIGNATURE- iD8DBQFHTp9rbjEdbHIsm0MRAml5AJ4/3KWm3YqTs7AEoqCFc/dGAj3CzQCgmX6K DJZ/qBt256GVy1NdYAwC2SU= =UnJw -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tim Polk wrote: There is no way to ensure that documents aren't published until *all* the appeals timers expire. Given that, let's encourage the RFC Editor to publish when ready, and we can concentrate on establishing a process that works when the appeal concerns a published document. +1 RFCs are withdrawn for a variety of reasons, already. A successful appeal would be merely one more. While no, historic is not metemantically identical to nevering having been published, it is sufficient that it means not approved by the IETF. Approval-vs-nonApproval seems like the most pragmatic test of reversal. The IETF approval process already has significant points of review and control. While this final-stage appeal potential is real, it does not happen with any frequency and the dangerous community impact of publishing an RFC that quickly gets moved to historic are small, possibly nil. Hence, no new mechanisms are need, although I do think it was useful to raise the question for discussion in this thread. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Dave Crocker wrote: Tim Polk wrote: There is no way to ensure that documents aren't published until *all* the appeals timers expire. Given that, let's encourage the RFC Editor to publish when ready, and we can concentrate on establishing a process that works when the appeal concerns a published document. +1 RFCs are withdrawn for a variety of reasons, already. A successful appeal would be merely one more. While no, historic is not metemantically identical to nevering having been published, it is sufficient that it means not approved by the IETF. Approval-vs-nonApproval seems like the most pragmatic test of reversal. The IETF approval process already has significant points of review and control. While this final-stage appeal potential is real, it does not happen with any frequency and the dangerous community impact of publishing an RFC that quickly gets moved to historic are small, possibly nil. Indeed, let's optimize for the common case. Hence, no new mechanisms are need, although I do think it was useful to raise the question for discussion in this thread. +1. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
--On Thursday, 29 November, 2007 11:16 +0100 Norbert Bollow [EMAIL PROTECTED] wrote: ... The point is that if IETF meetings are potentially repeat business for a hotel, that gives the hotel an otherwise-absent strong incentive to do such a good job that we'll want to hold another IETF meeting there. From the hotel's perspective, making sure that we don't get inconvenienced by renovations or other avoidable disruptions would be one aspect of that. But, Norbert, we are _not_ potentially repeat business for some of the hotels we have been in if they are charging anything close to their _normal_ conference (not rack or corporate rates). At least I hope they aren't, because I hope we never see an IETF meeting held at a hotel with room rates in the IETF block well over the USD 300 or EUR 300 range. And by the way, to review something that has been said in earlier versions of this discussion, even when we get an excellent room rate at a super-premium hotel, it may not necessarily be a good deal because eating or drinking at such a hotel tends to be at their normal super-premium rate. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
I agree with what Dave, Tim, and Harald said. Besides, if we really wanted a delay, we should pay the RFC Editor less and ask them to provide slower service :-) But please keep this as a secret from the IAOC... I would also like to point out its not the bits that are dangerous in a mistakenly or inappropriately approved document. It is the status that the IETF gives to these bits that matter. E.g., Proposed Standard, product of such and such WG. The bits are already out there in many places; we cannot withdraw them. What we can control is the status that the IETF gives for those bits. The modern tools we have for viewing IETF documents can make it plainly obvious to people what the status of an RFC is. But I would also caution a little bit against thinking that the solutions are easy. I think we should have a short deadline for notifying intent to appeal. However, a 5 page document may still get through the RFC Editor in a surprisingly small amount of time. And we can move a document to historic, but what about the other documents that referred to it? We can delay only the documents that we know will be appealed, but this appears to have obvious DoS problems. Nevertheless, I think repairing damage if it occurs is probably the right answer. Possibly combined with a short intent-to-appeal period, so that we can try to do the right thing as soon as possible. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Thursday, 29 November, 2007 01:18 -0800 Eric Rescorla [EMAIL PROTECTED] wrote: John, I agree with just about everything you say here, except for this: We may not even disagree completely about that. The key to my comment was irrelevant to _this_ discussion (emphasis added). More below. At Thu, 29 Nov 2007 01:56:51 -0500, John C Klensin wrote: And, incidentally, I believe that discussions about inherent conflicts of interest in the current appeals process are irrelevant to this discussion, for two reasons. First, as others have repeatedly pointed out, our appeals mechanisms are an important tool for reaching and establishing consensus, not a judicial procedure. Yes, it's not a judicial procedure, but nevertheless, an appeal of an IESG action inherently involves the claim that the IESG has made a mistake, and the IESG is not exactly in a position to judge that neutrally. Yes, the IESG does sometimes reverse itself, but there have also been times where the IESG has denied an appeal, the appellant has appealled to the IAB, and the IAB has upheld it. Having been involved in such cases, I don't think I would characterize them as establishing consensus. I agree. See below. And second, if there are conflicts of interest that we believe are unacceptable, and that belief is based on experience rather than theory or hypothetical situations, then we need to fix 2026 and the appeals process for reasons and in ways that have little to do with the publication delay question. I didn't say that there were COIs that were unacceptable. I said they needed to be mitigated by ensuring that the appellant had an opportunity to have a hearing before a neutral (or as neutral as possible) party. I think the current 2026 procedures more or less do that, but in this particular case there is a bug in the process. It's not one I'd ordinarily spend a lot of time agitating to fix, but since Russ raised the topic of delaying publication, it's worth getting this aspect of it straight. Well, the place where I think we disagree is _only_ about whether introducing the timing issue and the possible conditions for delaying publication changes anything. I'm not prepared to suggest a change to the procedures, in part because I'm not convinced it is a good idea and in part because I'm trying to go out of the business of suggesting new procedure models (partially for personal reasons and partially because I have come to believe that any significant change is impossible without first changing the approval procedure for such changes). However, I think that, for at least some cases, the appeals procedure should be redesigned so that: * we identify the body that is actually responsible for the decision being appealed. Sometimes that will be a WG Chair, sometimes an AD, sometimes the IESG. Empirically, it is typically the last person or body who has carefully considered a question (or should have) before the appeal about the decision on that question is initiated. * that body is neither expected nor permitted to make a formal writeup or response. The only question for it is does the content of this appeal raise issues that you didn't consider before, or didn't consider in enough depth, that, given its content you want to reopen the question and reconsider your own decision. The answer to that question requires reading the appeal and responding yes or no, not a long and agonizing process of writing and evaluating response text. Presumably, if they say yes, timers start running to prevent rejecting an appeal by sitting on it. * actual appeal processing then starts with the next body up the line or with an independent appeals-review body. That body can ask questions of the decision-making body and expect answers, but is not working from a record the decision-making body has prepared to refute the appeal. Actually changing to something like this would require sorting out a lot of details that I haven't even started to think about. But it might yield a somewhat cleaner and faster process. Then again, it might not, or it might not be worth the effort to design. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
On Thu, Nov 29, 2007 at 10:15:05AM +0100, Stephane Bortzmeyer wrote: It's not geographic balance of places on the world map that people are talking about here. It's geographic balance of places where the people who write IETF documents live. Then, things can go on forever. We do not hold meetings in places where there are not a lot of IETF members. As a result, people from these countries do not come and do not participate. Then, the prophecy becomes true. And so on. If we want to be serious about breaking the vicious circle, we should do meetings in places where there is *currently* few members (I do not suggest Namibia or Papua-New Guinea but, may be, Egypt, Argentina, India, places like that?) I would have to disagree. How useful is it for someone who isn't participating with the IETF to show up at an IETF meeting for the first time with zero context? The best way to participate is *on* *the* *mailing* *lists*. If we have the meeting in the middle of Africa, do you honestly expect anyone who shows up out of curiosity is likely to start authoring IETF documents and participating with the IETF after that one meeting is over? I personally have trouble beliving this - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John == John C Klensin [EMAIL PROTECTED] writes: John --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman John [EMAIL PROTECTED] wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. I agree that it is almost always desirable to delay publication once an appeal is filed. One critical assumption in my evaluation is that RFCs can be withdrawn. I'm quite confident that given a court order the RFC editor, the IETF website, etc, would find a way to remove an RFC. As such, we as a community can establish our own processes for withdrawing an RFC. John There would be copies floating around somewhere and it would John violate some important precedents. I agree that their would be copies floating around. I'm not sure how important I consider the precedents to be, although I agree they exist. John I agree that we could do John this, but I hope it would only occur in response to an John external and binding order (such as the court order of your John example) rather than an IETF/IESG adoption of some version John of newspeak. John Let me try to restate what I was trying to suggest (with John some changes after thinking about subsequent comments). However with two minor points I agree with your thoughts on how we should handle this situation. In particular, I strongly agree that with the possible exception of one appeal, publication delay was desirable for all past IESG appeals. I agree that 2026 does not need to be changed and that your proposed model seems reasonable. John Independent of how long it takes the IESG to make a final John decision about an appeal, agree about text, etc., I believe John that they are able to quickly make a decision about whether John or not the appeal is totally without merit (a criterion we John have discussed before and one that is very different from John direction it is likely to consider or other form of John pre-judgment). I also believe that the IESG is able to ask John the IAB to quickly consider a totally without merit John conclusion and reach their own conclusion about it. It is not clear to me that 1) The IAB would be willing to engage in such a dialogue with the IESG on an outstanding appeal. 2) If they engaged in the dialogue they would be willing to consider such a question or come to a decision. The IAB's stanse on appeals handling has always confused me. Section 6.5 of RFC 2026 talks about an open appeals process, but the IAB members involved in the IESG process have always wanted to make sure they don't have access to information related to an appeal even when that creates inconvenience. IAB members have created back pressure against IESG considering involving the community in discussing open appeals. I get the feeling that if we discussed an appeal at the plenary, some IAB mem members might object and the IAB might feel that it had to ask its members not to get involved in the discussion. I don't think the IAB or its members are being unreasonable. I think that the goals of the appeals process are confusing and that it would be useful for the community to give guidance on what it wants. On how to balance neutrality vs openness and on how to balance appeals process as a consensus tool against appeals process as something else. In practice things seem to work and so it doesn't bother me if these issues are never particularly resolved. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
--On Thursday, 29 November, 2007 10:16 +0100 Julian Reschke [EMAIL PROTECTED] wrote: Yes, you're taking this entire line of commentary completely out of context. This was all in response to Eliot's suggestion that XML versions of the document should be required at the time of WGLC. John K responded to that advising caution for various reasons and I chimed in with the additional reason that this will force people to generate standalone intermediary versions for submission. I'm aware of what started the discussion. However, when I use the submission tool today, I may not even know whether a particular version I submit will be a WGLC version. So I think whatever is the right answer for WGLC or LC is also the right answer for any ID version. In most of the WGs I've worked with in the last few years, the editor (and usually everyone else) know because there is an explicit discussion about which version is going to be used for for WGLC before it is posted. But assume my experience is abnormal. First, alternate cures for that problem include: (i) Permitting posting the XML when it becomes clear that a particular version is going to be the WGLC version, even after the text version has already been posted. (Whoops, not permitted by current automated tools and raises all of the same issues about proving synchronization that started this discussion.) (ii) Simply posting a new I-D, in both text and (for the first time) XML versions, once the WG concludes that it wants to initiate a WGLC. With I-D posting times now measured in minutes, rather than days, this is quite plausible, even if the only the date and version number change. (Whoops, we still have the synchronization problem -- if an editor wants to smuggle something in, nothing in the current tools checks that a posted text version is identical to XML, HTML, or PDF versions posted with it.) But WGLC is still the wrong time to _require_ posting XML, at least as long as we treat the text version as authoritative for review and approval purposes. The right time to post the XML is whenever the author or editor believes is the right time to post the XML, with the understanding that posting it earlier rather than later may be convenient for some WG members or reviewers but that there are many reasons to delay its posting, many of which Ned and I have summarized. If anyone, including the RFC Editor, is going to use an XML version for anything in, or at the end of, the approval process, they clearly have the responsibility to verify that it is a reasonable match for the text and, if there are differences, that those differences are acceptable.Note that this same issue arises when an editor submits a revised text form to the RFC Editor or to an AD for editing/ review convenience -- it ultimately has little to do with whether XML is involved and both happen. If one is looking for a guarantee that an XML version matches the published text without verifying it oneself, that guarantee comes only when the RFC Editor posts the XML. Even that reflects only textual identity because it is perfectly plausible for the RFC Editor to process the XML into nroff (or the formatting language of their choice) and then use the nroff to fine-tune details of page layout. XML generally, and xml2rfc in particular, do not specify page format to nearly the degree that may be appropriate for a published RFC. To fix them to do so would remove much of the attraction of generic markup. So, at least in retrospect, the whole theme of this thread seems to me to have been misguided. What we have is: (1) When XML is submitted to the RFC Editor, it would be helpful to the RFC Editor if the editor supplied a note indicating how, if at all, it differed from the posted version. With or without such warnings, the RFC Editor needs to verify things submitted to them in XML form to verify that they adequately match the text -- and that is true both of initial submission versions and anything comes back in from AUTH48 correspondence. Fortunately, being sensible and careful people, the RFC Editor is doing that already. (2) If the RFC Editor accepts changes from an author (or AD) that they should not be accepting, it is a problem that has little to do with whether those changes are submitted in the XML, in text, in the old change this to that form, or over the telephone. Opinions differ in the community as to the extent of changes the RFC Editor should be able to make without asking for permission and the changes an AD should be able to approve without asking for a new Last Call, but those are not XML submission issues. (3) Authors, editors, and
Re: IETF Hosting Opportunity - March 2009
--On Thursday, 29 November, 2007 10:15 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: It's not geographic balance of places on the world map that people are talking about here. It's geographic balance of places where the people who write IETF documents live. Then, things can go on forever. We do not hold meetings in places where there are not a lot of IETF members. As a result, people from these countries do not come and do not participate. Then, the prophecy becomes true. And so on. Stephane, If you believe this, it could easily be used to go back a decade and used to prove that we would never hold a meeting in either Europe or Asia. Such a proof would clearly be false, since people from those regions started participating actively and writing documents without the presumed benefits of showpiece meetings in their immediate vicinity. This isn't about making the IETF accessible to people. It is about the end of the horse on which the cart is to be placed. Of course, if we were to decide that we would like to be more like those organizations in which most of the work is done at meetings and a great deal of the purpose of a meeting is to act as a showpiece for the organization in some particular region or country, these considerations would change. I've had enough experience with those organizations and the related side-effects that I hope we don't go there. Ever. YMMD, but, if that were to be even part of your goal, I think you should be explicit about it, not raise spurious arguments about how people won't participate unless we start holding meetings in their city/ country/ region. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Eurasia
Why do IETF meetings have to be monolithic and all-inclusive? I can tell you why we do - crosstalk. It can be incredibly useful for people from the Security Area to look in on Applications, or for Transport and RAI folks to understand the workings of the layers beneath them and their users, for example. That doesn't make for a has to, but it seems like a good reason to choose to, from my perspective. I agree with your reasoning. I should have asked, why do *ALL* IETF meetings have to be monolithic and all-inclusive? Smaller meetings held outside North America could be located in smaller cheaper hotels, and would encourage wider participation in the IETF. In fact, smaller meetings in North America would achieve the same ends. I'm not suggesting getting rid of the existing monolithic meetings, but adding another type of meeting that is smaller, cheaper to attend, and held in cities/countries that are far from the USA but closer to people who should be more involved in the IETF. For instance, Pune and Bangalore India, Moscow and Ekaterinburg Russia, Dalian and Shanghai China as well as places like Helsinki, Frankfurt, Tokyo, Seoul. Note that smaller regional meetings still provide the opportunities for some crosstalk, even if the variety of WG choices to attend will be smaller. And it increases the amount of crosstalk and cross-fertilization between people who regularly work in the IETF and those who have not done IETF work because they have not had the opportunity to see it in action, face to face. Note also that RIPE does something along these lines with their regional meetings having more focus on education. I expect that an IETF regional meeting would also have to have more focus on education since a higher proportion of first-timers would attend. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At 3:33 PM +0200 11/29/07, Jari Arkko wrote: And we can move a document to historic, Note that there are two different no process change needed proposals on the table: obsoleting with NULL (or a bit of explanation) and moving to Historic. Obsoleting a document is much easier for the outside world to understand than changing its status to Historic, given that we have many different reasons for Historic. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Paul == Paul Hoffman [EMAIL PROTECTED] writes: Paul At 3:33 PM +0200 11/29/07, Jari Arkko wrote: And we can move a document to historic, Paul Note that there are two different no process change needed Paul proposals on the table: obsoleting with NULL (or a bit of Paul explanation) and moving to Historic. Obsoleting a document Paul is much easier for the outside world to understand than Paul changing its status to Historic, given that we have many Paul different reasons for Historic. I'd assume that you want to do both. Remember that obseleting a document does not imply it goes to historic. I've never fully agreed with that bit of rfc-editor-process trivia. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Vancouver Update
At 10:55 PM -0800 11/28/07, Cullen Jennings wrote: Wow. That greatly exceeded my expectations for a resolution. Thanks to everyone who made that happen. I agree, and I second the thanks. I want to thank, in particular, the Secretariat staff who volunteered to be relocated. Given the current situation and the enormous amount of work that they do to put on an IETF meeting, this is an act of selflessness that goes beyond the professionalism and kindness we have come to expect. It means, basically, that they will be adding time and removing rest opportunities from days that are already longer and busier than even those of the IESG or IAB. Many thanks, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
John C Klensin wrote: But a hotel has a special incentive to offer us (or any other candidate for holding meetings or taking up a lot of rooms) very low rates (measured in the differential from their average rack rate or even their standard corporate rate) when, for some reason or another, they expect a John, Actually I believe I did understand the original point. I was attempting to counter it, by pointing out that any renter, at any rate, has reasonable expectations that a facility will be usable. When a hotel makes choices that would render the facility unusuable for us, they have violated the core of the agreement, no matter the nature of the problem that renders the facility unusable. I do not see the mere fact of any renovations as making a place unusable. However, failure to honor reservations, running jackhammers next to meeting rooms, and the like, do. So, again, I think there is a big difference between things that alter degrees of convenience or, perhaps, environmental aesthetics, versus things that make the facility unusable. I see this is a simple issue that is not very subtle. If a hotel cannot guarantee reasonable usability, then no rate is low enough. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
--On Thursday, 29 November, 2007 08:42 -0500 Dave Crocker [EMAIL PROTECTED] wrote: ... I do not see the mere fact of any renovations as making a place unusable. However, failure to honor reservations, running jackhammers next to meeting rooms, and the like, do. So, again, I think there is a big difference between things that alter degrees of convenience or, perhaps, environmental aesthetics, versus things that make the facility unusable. I see this is a simple issue that is not very subtle. If a hotel cannot guarantee reasonable usability, then no rate is low enough. In a backwards sort of way, I think we agree... we are just looking at this from different perspectives. If a hotel offers us a cheap rate but doesn't bother to tell us about the jackhammers, even if we ask, then there is some very bad behavior going on. And, if they offer us a sufficiently cheap rate relative to their norms, I believe we should be questioning the deal very carefully. If a hotel says well, we are remodeling, but we are sure it won't inconvenience you in any way, and here is this super-cheap rate, I think we need to view the rate with great suspicion and treat the promise the way we treat commitments from the average snake-oil salesman, especially because we know from experience that on-site hotel staff (even ones we know well) often have little control over construction contractors who have their own supervisors, contracts, deadlines, etc. Where we may differ is that I think we have enough experience at this point to know that, if there is going to be significant construction/ renovation going on, guarantees of reasonable usability are meaningless in practice and your no rate is low enough principle applies. If they make a guarantee and then can't keep it after we arrive, or even behave in particularly egregious ways (of which canceling reservations would certainly be an instance), all we can do then is talk about penalties. And, while penalties may help us feel good, may help the budget, and the meeting fees a year out, they don't do a thing to help us recover lost productivity or lost time. So I am suggesting that, unless as part of the deal, Ray and the IAOC are able to actually get the construction plans, form their own opinions about the likelihood of disruption, and, to the extent needed, and verify and get commitments from the construction firm about non-interference, it is time we start considering doing some renovations to be a hard negative on a particular facility, regardless of what rates they are offering us. And part of that is that, if a hotel guarantees us no renovation work, the penalties for breaking _that_ guarantee should be painful and set in whether we are actually disrupted or not, just to make sure it is clear that behavior is unacceptable and non-negotiable. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Westin Bayshore throwing us out
-Original Message- From: Cullen Jennings [mailto:[EMAIL PROTECTED] Actually, I'm interested in a more basic thing. We usually put a large load on a hotel. Why don't our contracts insist that the hotel not be undergoing significant renovation during the meeting. One of the problems is that the venue agreements are made pretty far in advance, and hotels make renovation decisons on shorter timeframes. So you may make a venue selection 1 1/2 years before a meeting, and find out 1 year before the meeting of a renovation. Jason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Westin Bayshore throwing us out
For the record, Ray was aware of this renovation, and tells us that there will be renovation ongoing in Philadelphia as well. Ray can comment more, but the renovation in Philly for IETF 71 (discovered after the venue decision I believe) is of some of the common areas in the bar and does not involve renovations to the guest rooms. I will also note that in Philadelphia, there are a plethora of hotels to choose from within a block or two walk from the venue as well (in addition to good subway systems, etc.). Jason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
On 11/29/07 at 10:15 AM +0100, Stephane Bortzmeyer wrote: On Wed, Nov 28, 2007 at 11:23:10AM -0600, Pete Resnick [EMAIL PROTECTED] wrote a message of 22 lines which said: It's not geographic balance of places on the world map that people are talking about here. It's geographic balance of places where the people who write IETF documents live. Then, things can go on forever. We do not hold meetings in places where there are not a lot of IETF members. As a result, people from these countries do not come and do not participate. Then, the prophecy becomes true. And so on. Nonsense. As Alexey pointed out, in the Apps area we have plenty of participants who are from places in which we rarely meet. Some contribute to mailing lists, others actually write I-Ds. In the grand tradition of the IETF, showing up for meetings is not required to be a successful participant. Sure, it's helpful to go to meetings to work out thorny issues, but it should by no means be required. On a tangential point: Some folks in the IETF think that meetings should be for presentations and tutorials, or to make more-or-less final decisions on open topics because nobody does anything on the mailing list. I tend not to go to such meetings and whine about them when I have to go. If that's your idea of a good use of IETF meeting time, then I see why you would think that meeting in places with few participants would be a good thing: Working on those mailing lists isn't all that useful and you can't be a good participant without going to the meetings. To me, that says that we should change WG chairs or ADs, not meeting locations. If we want to be serious about breaking the vicious circle, we should do meetings in places where there is *currently* few members (I do not suggest Namibia or Papua-New Guinea but, may be, Egypt, Argentina, India, places like that?) India is becoming interesting because (a) we're getting more folks from India participating and (b) the mean-time-to-travel to any place on earth for current participants might be trending toward India. (We've got more folks in east Asia who would have a shorter trip to India than to Europe or North America, and there are now direct flights over the pole between North America and India.) Finding a large enough venue in India is a different problem. Personally, on similar mean-time-to-travel grounds, St. Johns in Newfoundland looks interesting. :-) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
Hi, Thanks for your comment on 2929bis. See response below at @@@ -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 5:08 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG [EMAIL PROTECTED] wrote a message of 24 lines which said: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from IETF consensus to the new DNS RRTYPE Allocation Policy in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: a Meta-Type who processing is optional, I believe it should be whose processing). @@@ Thanks for finding this typo. But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), @@@ I do not see any reason to provide for extension of consideration or mid-stream modification to applications. The Expert is required by 2929bis to monitor namedroppers discussion of applications for an RR Type and applicants are encouraged by 2929bis to informally post applications to get feedback. So the applicant should normally have early feedback from the Expert. In cases where the formal application is rejected and the Expert provides suggested changes, it seems simpler and cleaner for the applicant to resubmit, rather than modify. This also fits with the DNSEXT WG consensus that the namedroppers community have three weeks to examine any application, to reduce the chance of someone missing something because they are on vacation or the like, rather than the more common IETF posting requirement of two weeks (which is used in 4646bis). @@@ I personally don't see why someone would think there is a time extension or mid-stream change facility for 2929bis when none is provided in the document; but I don't object to adding a few words to make this clear. * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, @@@ This is probably a good point. The addition of a specific requirement for the assigned Expert to post an acceptance or rejection (presumably to IANA, namedroppers, and the applicant) within a reasonable period of time, such as six weeks from the formal posting of the completed template to namedroppers, seems reasonable to me. * appeals to the IESG @@@ I see no need to include this. 2929bis normatively references RFC 2434 which says: @@@Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. May be such wording should appear in draft-ietf-dnsext-2929bis? @@@ How about adding the following to Section 3.1.1? @@@ After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. @@@ Thanks again, @@@ Donald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Hotel selection
From: Fred Baker [mailto:[EMAIL PROTECTED] One question I would ask the peanut gallery is: if we were to pick a small set of venues to return to, which would we pick? The ones I might think of would include our recent venues in Paris and Prague, the Minneapolis Hilton, the facility we were at in Dallas last year (although restaurants weren't very convenient) I would actually vote strongly against venues such as the Dallas venue. Given that we have over 1,000 people coming into each venue, it seems odd to expect everyone to rent cars and otherwise go somewhere that is relatively remote from other services. IMHO, ideal venues are in city centers, where people can walk from the venue to a wide variety of other hotels and restaurants, and where public transportation is available to connect between airports and regional rail systems and to other parts of the venue's city. This tends to decrease the travel costs and hassles for attendees, among other benefits. Jason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Eurasia
[EMAIL PROTECTED] wrote: Why do IETF meetings have to be monolithic and all-inclusive? || ||| I can tell you why we do - crosstalk. It can be incredibly useful ||| for people from the Security Area to look in on Applications, or for ||| Transport and RAI folks to understand the workings of the layers ||| beneath them and their users, for example. ||| ||| That doesn't make for a has to, but it seems like a good reason to ||| choose to, from my perspective. || || I agree with your reasoning. I should have asked, why do || *ALL* IETF meetings have to be monolithic and all-inclusive? || || Smaller meetings held outside North America could be located || in smaller cheaper hotels, and would encourage wider || participation in the IETF. In fact, smaller meetings in || North America would achieve the same ends. || || I'm not suggesting getting rid of the existing monolithic || meetings, but adding another type of meeting that is || smaller, cheaper to attend, and held in cities/countries || that are far from the USA but closer to people who should be || more involved in the IETF. For instance, Pune and Bangalore || India, Moscow and Ekaterinburg Russia, Dalian and Shanghai || China as well as places like Helsinki, Frankfurt, Tokyo, Seoul. || || Note that smaller regional meetings still provide the || opportunities for some crosstalk, even if the variety of WG || choices to attend will be smaller. And it increases the || amount of crosstalk and cross-fertilization between people || who regularly work in the IETF and those who have not done || IETF work because they have not had the opportunity to see || it in action, face to face. || || Note also that RIPE does something along these lines with || their regional meetings having more focus on education. I || expect that an IETF regional meeting would also have to have || more focus on education since a higher proportion of first-timers || would attend. Wouldn't the regional meetings you are suggesting have a totally different focus and be a different type of event all together compared to the main meetings currently? I would expect such regional meetings to have a focus on educating the local public about the IETF and be about increasing participation but not including any actual work on IETF content. Believe such regional meetings would be a great idea as a means to facilitate mentoring of future participants and encouraging new blood into the organization. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
On Thu, Nov 29, 2007 at 04:16:19PM -0500, Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote a message of 103 lines which said: How about adding the following to Section 3.1.1? After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. It seems fine to me. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
On 11/29/07 2:00 PM, Livingood, Jason wrote: ...[T]he renovation in Philly for IETF 71 (discovered after the venue decision I believe) is of... the bar. Well, there goes any hope of getting anything useful done in Philly. :) /a ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF 71 Info
FYI, in addition to the typical info that will be on the web in advance of IETF 71, we setup a site that will soon include additional logistical and city information. It's pretty basic at the moment, but you can subscribe to the RSS feed if you like. The hope is to provide a little extra info for attendees to make coming to IETF 71 a little easier for attendees. The URL is http://ietf71.comcast.net Much more will be added to this site once IETF 70 has concluded (and I will probably work on it while in Vancouver). Email me privately if there is anything you think is really useful for attendees. Regards Jason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Westin Bayshore throwing us out
They will have a special bar area setup for attendees. There are also several other bars inside the hotel building (including a sports bar) and probably 10 - 15 bars within a 1 to 2 block radius. I believe the liquid consumption needs of attendees will be easily accomodated. :-) We'll be posting at http://ietf71.comcast.net a guide to all of the local bars and the distances from the hotel lobby in the coming weeks and months before IETF 71. Jason -Original Message- From: Adam Roach [mailto:[EMAIL PROTECTED] Sent: Thursday, November 29, 2007 5:11 PM To: Livingood, Jason Cc: Fred Baker; Cullen Jennings; Pete Resnick; ietf@ietf.org Subject: Re: Westin Bayshore throwing us out On 11/29/07 2:00 PM, Livingood, Jason wrote: ...[T]he renovation in Philly for IETF 71 (discovered after the venue decision I believe) is of... the bar. Well, there goes any hope of getting anything useful done in Philly. :) /a ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Westin Vancouver Update
I would like to add my thanks as well. The contrast between IETF/Neustar and the Westin staff (who still can't get my reservation right) is quite striking. Y(J)S -Original Message- From: Ted Hardie [mailto:[EMAIL PROTECTED] Sent: Thursday, November 29, 2007 7:24 PM To: Ray Pelletier Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Westin Vancouver Update At 10:55 PM -0800 11/28/07, Cullen Jennings wrote: Wow. That greatly exceeded my expectations for a resolution. Thanks to everyone who made that happen. I agree, and I second the thanks. I want to thank, in particular, the Secretariat staff who volunteered to be relocated. Given the current situation and the enormous amount of work that they do to put on an IETF meeting, this is an act of selflessness that goes beyond the professionalism and kindness we have come to expect. It means, basically, that they will be adding time and removing rest opportunities from days that are already longer and busier than even those of the IESG or IAB. Many thanks, Ted ___ 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: IETF Hosting Opportunity - March 2009
Pete Resnick wrote: India is becoming interesting because (a) we're getting more folks from India participating and (b) the mean-time-to-travel to any place on earth for current participants might be trending toward India. (We've got more folks in east Asia who would have a shorter trip to India than to Europe or North America, and there are now direct flights over the pole between North America and India.) Finding a large enough venue in India is a different problem. In the past, willing hosts who can make the costs pencil out have succeeded in in hosting meetings in well connected locations that are a substantial distance from either the united states or europe. The collective set of volunteers the secretariat have made hostless meetings work in locations where they have access to resources. It doesn't seem to be reasonable or workable for the IAOC to attempt meeting venues were there are neither hosts with resources (which variously in the past have included, hands, facilities, circuits, capital, government contacts etc) or ietf participants who are not hosts with access to similar resources. The evolution of the hosting model hasn't thus far (in my experience) eliminated this dependency on the efforts of hosts and/or resources that members of community have access to. Every meeting that I have been involved in since 37 located in the US or outside, perceived to be successful network or otherwise has thus far leveraged those sorts of resources to a lesser or greater extent. If we have resources we can leverage in India there's no reason to be believe that we can't host a successful meeting there. certainly there are well connected cities with usable venues. Personally, on similar mean-time-to-travel grounds, St. Johns in Newfoundland looks interesting. :-) Not, the coldest venue thus far... pr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 194 messages in the last 7 days. script run at: Fri Nov 30 00:53:02 EST 2007 Messages | Bytes| Who +--++--+ 9.28% | 18 | 8.67% |94549 | [EMAIL PROTECTED] 5.15% | 10 | 6.15% |67110 | [EMAIL PROTECTED] 5.67% | 11 | 4.77% |51991 | [EMAIL PROTECTED] 4.64% |9 | 3.51% |38345 | [EMAIL PROTECTED] 3.09% |6 | 4.76% |51900 | [EMAIL PROTECTED] 3.61% |7 | 2.92% |31850 | [EMAIL PROTECTED] 3.09% |6 | 3.31% |36121 | [EMAIL PROTECTED] 2.58% |5 | 2.86% |31201 | [EMAIL PROTECTED] 2.58% |5 | 2.51% |27402 | [EMAIL PROTECTED] 2.58% |5 | 2.33% |25383 | [EMAIL PROTECTED] 2.58% |5 | 2.18% |23803 | [EMAIL PROTECTED] 2.58% |5 | 2.13% |23242 | [EMAIL PROTECTED] 2.06% |4 | 2.14% |23294 | [EMAIL PROTECTED] 1.55% |3 | 2.61% |28501 | [EMAIL PROTECTED] 2.06% |4 | 1.85% |20160 | [EMAIL PROTECTED] 2.06% |4 | 1.84% |20123 | [EMAIL PROTECTED] 2.06% |4 | 1.75% |19133 | [EMAIL PROTECTED] 2.06% |4 | 1.65% |17994 | [EMAIL PROTECTED] 1.55% |3 | 1.61% |17612 | [EMAIL PROTECTED] 1.55% |3 | 1.42% |15496 | [EMAIL PROTECTED] 1.55% |3 | 1.37% |14955 | [EMAIL PROTECTED] 1.55% |3 | 1.34% |14586 | [EMAIL PROTECTED] 1.55% |3 | 1.30% |14214 | [EMAIL PROTECTED] 1.55% |3 | 1.30% |14196 | [EMAIL PROTECTED] 1.55% |3 | 1.25% |13672 | [EMAIL PROTECTED] 1.03% |2 | 1.43% |15592 | [EMAIL PROTECTED] 1.03% |2 | 1.23% |13398 | [EMAIL PROTECTED] 0.52% |1 | 1.71% |18687 | [EMAIL PROTECTED] 1.03% |2 | 1.16% |12656 | [EMAIL PROTECTED] 1.03% |2 | 1.06% |11603 | [EMAIL PROTECTED] 1.03% |2 | 1.06% |11561 | [EMAIL PROTECTED] 0.52% |1 | 1.54% |16832 | [EMAIL PROTECTED] 1.03% |2 | 1.00% |10933 | [EMAIL PROTECTED] 1.03% |2 | 0.94% |10285 | [EMAIL PROTECTED] 1.03% |2 | 0.94% |10241 | [EMAIL PROTECTED] 1.03% |2 | 0.89% | 9688 | [EMAIL PROTECTED] 1.03% |2 | 0.86% | 9404 | [EMAIL PROTECTED] 1.03% |2 | 0.75% | 8183 | [EMAIL PROTECTED] 0.52% |1 | 1.13% |12282 | [EMAIL PROTECTED] 0.52% |1 | 1.09% |11837 | [EMAIL PROTECTED] 0.52% |1 | 0.81% | 8885 | [EMAIL PROTECTED] 0.52% |1 | 0.69% | 7485 | [EMAIL PROTECTED] 0.52% |1 | 0.64% | 6947 | [EMAIL PROTECTED] 0.52% |1 | 0.63% | 6893 | [EMAIL PROTECTED] 0.52% |1 | 0.57% | 6242 | [EMAIL PROTECTED] 0.52% |1 | 0.56% | 6125 | [EMAIL PROTECTED] 0.52% |1 | 0.55% | 6014 | [EMAIL PROTECTED] 0.52% |1 | 0.54% | 5935 | [EMAIL PROTECTED] 0.52% |1 | 0.54% | 5877 | [EMAIL PROTECTED] 0.52% |1 | 0.52% | 5700 | [EMAIL PROTECTED] 0.52% |1 | 0.51% | 5607 | [EMAIL PROTECTED] 0.52% |1 | 0.51% | 5536 | [EMAIL PROTECTED] 0.52% |1 | 0.50% | 5454 | [EMAIL PROTECTED] 0.52% |1 | 0.49% | 5376 | [EMAIL PROTECTED] 0.52% |1 | 0.49% | 5361 | [EMAIL PROTECTED] 0.52% |1 | 0.48% | 5241 | [EMAIL PROTECTED] 0.52% |1 | 0.47% | 5155 | [EMAIL PROTECTED] 0.52% |1 | 0.46% | 5066 | [EMAIL PROTECTED] 0.52% |1 | 0.46% | 5035 | [EMAIL PROTECTED] 0.52% |1 | 0.46% | 4975 | [EMAIL PROTECTED] 0.52% |1 | 0.44% | 4831 | [EMAIL PROTECTED] 0.52% |1 | 0.44% | 4831 | [EMAIL PROTECTED] 0.52% |1 | 0.42% | 4611 | [EMAIL PROTECTED] 0.52% |1 | 0.41% | 4513 | [EMAIL PROTECTED] 0.52% |1 | 0.41% | 4473 | [EMAIL PROTECTED] 0.52% |1 | 0.40% | 4355 | [EMAIL PROTECTED] 0.52% |1 | 0.40% | 4318 | [EMAIL PROTECTED] 0.52% |1 | 0.40% | 4313 | [EMAIL PROTECTED] 0.52% |1 | 0.39% | 4227 | [EMAIL PROTECTED] 0.52% |1 | 0.38% | 4137 | [EMAIL PROTECTED] 0.52% |1 | 0.38% | 4127 | [EMAIL PROTECTED] 0.52% |1 | 0.30% | 3276 | [EMAIL PROTECTED] +--++--+ 100.00% | 194 |100.00% | 1090936 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
India is also becoming significant in terms of well trained graduate IT engineers and certified engineers, it can be more interesting if these IT engineers are more involved in activities of IETF, ISOC, ICANN and other standards related organizations. Probably initiatives can start during their graduate and certification course work by means of having to study a subject related with standards. Right now IT engineers awareness even existence of IEEE or the term 802.xx is very minimum. but in terms of connectivity to major Indian cities are good and with Bangalore like place there are venues available closely matching International level. ISOC fellowships concept needs big appreciation this goes long way in developing countries like India will see major participation in IETF activities and in future India can be venue for IETF meetings. Rajesh India On Nov 29, 2007 8:22 PM, Joel Jaeggli [EMAIL PROTECTED] wrote: Pete Resnick wrote: India is becoming interesting because (a) we're getting more folks from India participating and (b) the mean-time-to-travel to any place on earth for current participants might be trending toward India. (We've got more folks in east Asia who would have a shorter trip to India than to Europe or North America, and there are now direct flights over the pole between North America and India.) Finding a large enough venue in India is a different problem. In the past, willing hosts who can make the costs pencil out have succeeded in in hosting meetings in well connected locations that are a substantial distance from either the united states or europe. The collective set of volunteers the secretariat have made hostless meetings work in locations where they have access to resources. It doesn't seem to be reasonable or workable for the IAOC to attempt meeting venues were there are neither hosts with resources (which variously in the past have included, hands, facilities, circuits, capital, government contacts etc) or ietf participants who are not hosts with access to similar resources. The evolution of the hosting model hasn't thus far (in my experience) eliminated this dependency on the efforts of hosts and/or resources that members of community have access to. Every meeting that I have been involved in since 37 located in the US or outside, perceived to be successful network or otherwise has thus far leveraged those sorts of resources to a lesser or greater extent. If we have resources we can leverage in India there's no reason to be believe that we can't host a successful meeting there. certainly there are well connected cities with usable venues. Personally, on similar mean-time-to-travel grounds, St. Johns in Newfoundland looks interesting. :-) Not, the coldest venue thus far... pr ___ 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
Last Call: draft-ietf-sipping-capacity-attribute (Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists) to Proposed Standard
The IESG has received a request from the Session Initiation Proposal Investigation WG (sipping) to consider the following document: - 'Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists ' draft-ietf-sipping-capacity-attribute-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-12-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-capacity-attribute-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14330rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sipping-consent-format (A Document Format for Requesting Consent) to Proposed Standard
The IESG has received a request from the Session Initiation Proposal Investigation WG (sipping) to consider the following document: - 'A Document Format for Requesting Consent ' draft-ietf-sipping-consent-format-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-12-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-format-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15179rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sipping-pending-additions (The Session Initiation Protocol (SIP) Pending Additions Event Package) to Proposed Standard
The IESG has received a request from the Session Initiation Proposal Investigation WG (sipping) to consider the following document: - 'The Session Initiation Protocol (SIP) Pending Additions Event Package ' draft-ietf-sipping-pending-additions-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-12-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-pending-additions-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15178rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sipping-uri-services (Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services) to Proposed Standard
The IESG has received a request from the Session Initiation Proposal Investigation WG (sipping) to consider the following document: - 'Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services ' draft-ietf-sipping-uri-services-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-12-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-services-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12014rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC Editor Office Hours -- IETF 70
Greetings, The RFC Editor will be holding office hours at IETF-70, Vancouver, Canada. This is a chance for a face-to-face inquiry into the status of pending documents or just a chance to ask questions about how the RFC Editor works. The RFC Editor office will be a table near the IETF registration area, staffed during the following hours: Monday - Wednesday 930 - 1600 If you have questions regarding specific documents, we would appreciate it if you could send us a note in advance so that we can be more efficient in answering your questions. If you relay the ID string to us, we will have the opportunity to review the history of the document, as we will not be able to bring all of the documents with us. However, this isn't required and drop-ins are encouraged. Also, please note that the RFC Editor will be participating in the Document Lifecycle Tutorial that will be held on Sunday (2 December 2007 -- 15:00 - 16:45). We look forward to meeting (all of) you, Sandy and Alice (for the RFC Editor) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8 at the Vancouver Meeting
Folks, The nomcom has been busy with the selection process over the past several months reviewing candidates' questionnaire responses, processing community feedback and gearing up to make use of the face-to-face time at the Vancouver meeting as effectively as possible. We have scheduled some interviews at the Vancouver meeting and may schedule additional interviews with candidates over the phone or may ask for additional information via email. If you are a candidate, we very much appreciate your patience while we work on the selections. We are slightly behind in our schedule, but expect to send out requests for feedback on IAB and IAOC candidates in the next few days. While the community provides feedback on the IAB and IAOC candidates, we plan to finalize the selections for the open IESG positions. We hope that this parallelization will put us back on track to meet the deadlines. We will make all attempts to meet the posted deadlines. Nomcom members will continue to listen to community feedback at the Vancouver meeting. Please send an email to one of the nomcom members or me directly to setup a time to chat about the selections this year. Thank you again for the nominations and feedback on candidates. best regards, Lakshminath 2007-8 Nomcom Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
