Re: [Tools-discuss] independant submissions that update standards track, and datatracker
On 10/2/2013 9:15 AM, Scott O Bradner wrote: 1 April RFCs excepted Ah. I'm sitting here banging my head on a desk thinking I knew that ... thanks, Scott! Spencer
Re: feedback blog entry
On 9/24/2013 1:22 PM, IETF Chair wrote: SM: Thanks for the feedback. I read the article. As a comment about the last paragraph, the metric being used is not the best in my humble opinion. You are referring to attendance and authoring RFCs? I agree, of course. I apologize for using a metric that is, at best, partial. My only defense is that it was what I had easily available :-( I do realise that real engagement from different types of organisations and people and areas of the world goes to far more fundamental issues than showing numbers of people. True involvement and effect is what counts. As we know, that does not necessarily correlate with any particular statistic... Spencer Dawkins made an insightful comment which I would look into if I was looking for a better metric. Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what you are referring to. I'd be interested in better metrics. Hi, Jari, I'm not saying that I make so many insightful comments that I can't keep them straight, but I wasn't sure, either :D I'm guessing SM is referring to this one ... https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k3=12404k4=1tid=1380055577 Spencer
Re: ORCID - unique identifiers for contributors
On 9/18/2013 8:59 AM, John C Klensin wrote: Andy, we just don't have a tradition of identifying people whose contributed to RFCs with either contact or identification information. It is explicitly possible when Contributors sections are created and people are listed there, but contact or identification information is not required in that section, rarely provided, and, IIR, not supported by the existing tools. That doesn't necessarily mean that doing so is a bad idea (although I contend that getting it down to listings in Acknowledgments would be) but that making enough changes to both incorporate the information and make it available as metadata would be a rather significant amount of work and would probably reopen policy issues about who is entitled to be listed. If I learned nothing else while mis-spending the mid-2000s talking about IETF process change, it's that if you want anything to change, take the first step toward changing it. If you can come up with a URN definition for ORCID and stuff it into your own author block as a URI without asking for permission or tooling changes, and you think doing so would be helpful, do it. If three people include ORCIDs in their contact information during the next two years, we're probably done. If 300 people do it, we can talk about whether that turned out to be useful, and whether taking some other step would be useful, too. There have been (counting me) four sitting ADs posting on this 90-email thread, plus another six or so former ADs, including a former IETF chair, plus at least six or so WG chairs, plus other participants of good mind and good hearts. I'm thinking that if it was possible to reason what the right answer should be, we would have all agreed. Perhaps we've all agreed (dear Jari, did we all agree?), but if not, the next step could be to try something, and see if it's good enough, or if we need to try something else. Spencer
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 9/6/2013 10:46 AM, Ted Lemon wrote: The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing. The problem is the breathtakingly irresponsible weakening of crypto systems that has been alleged here, and what we can do to mitigate that. Even if we aren't sure that it's happened, or precisely what's happened, it's likely that it has happened, or will happen in the near future. We should be thinking in those terms, not crossing our fingers and hoping for the best. IIUC, I'm with Ted. We should be thinking in those terms, and thinking broadly. I have to wonder whether weakening crypto systems to allow pervasive passive monitoring by national agencies would weaken them enough for technologically savvy corporations to monitor their competitors, for instance. Spencer
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 9/6/2013 11:38 AM, Noel Chiappa wrote: From: Spencer Dawkins spencerdawkins.i...@gmail.com I have to wonder whether weakening crypto systems to allow pervasive passive monitoring by national agencies would weaken them enough for technologically savvy corporations to monitor their competitors, for instance. More importantly, if crypto systems are weaked so that the intelligence agencies of the 'good guys' can monitor them, they're probably weak enough that the intelligence agencies of the 'bad guys' can monitor them too. The smarts level on the other side should not be under-estimated, although I fear this often happens. Noel, I agree that's important (and perhaps more important), and that underestimating 'bad guys' is all too tempting, and all too easy. I thought to call attention to the opportunities for commercial leakage, from everything from trade secrets to medical records, if our strong crypto turns out to contain intentional weaknesses. We have plenty of potential exposures to worry about, depending on who's likely to be interested in seeing what we're trying to hide. Spencer
Re: PS Characterization Clarified
On 9/4/2013 11:14 AM, Scott Brim wrote: On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba barryle...@computer.org wrote: The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do option. Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) That's a good point; probably yes. So if the text here can say something that allows a PS spec to *say* that it's less mature, and that that's being done on purpose, my concern is satisfied. Not the spec itself but an associated statement about it? There was a proposal to provide an alternative way of publishing applicability statements, in http://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04 (now expired). As a specific current example, I have the sense that the documents coming out of the repute working group are specifying a protocol that's somewhat less mature than what we usually do -- more comparable to the 2026 version of PS than to this one. Yet I absolutely think they should be PS, *not* Experimental. OK, somebody has to say it. Maybe we should have another state, something like draft standard. There were a couple of proposals to provide a way of saying the working group thinks they're finished, but lets hold off on PS until they see how the protocol works. The one I co-authored was at http://tools.ietf.org/html/draft-dawkins-newtrk-wgs-00, Scott Bradner's was at http://tools.ietf.org/html/draft-bradner-ietf-stds-trk-00, in Section 5. Both are now expired. Perhaps those drafts would be helpful background for folks thinking about this? (especially for folks who were too busy doing protocol work to follow NEWTRK? :-) Spencer
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/3/2013 9:26 AM, Scott Kitterman wrote: S Moonesamy sm+i...@elandsys.com wrote: The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. Except for the part between the commas it's great. As written, it presumes that a mis-communication between a native speaker of English and someone who isn't is the fault of the native speaker. I don't think this is appropriate. Hi, Scott, Keeping in mind that we wouldn't be looking at this text in the first place, if it was easy to communicate ... ;-) What I thought the parenthetical presumed, was that a native English speaker(*) might have more tools to use in helping repair mis-communication - for example, a native English speaker might have a larger vocabulary, if paraphrasing would help understanding, and might be more likely to use obscure English idioms(**) that don't translate easily into other languages and cultures. So, not that mis-communication is the native English speaker's fault, but that the native English speaker might be better positioned to make the first move to improve communication. Spencer (*) Obviously there are people, including people at the IETF, who learned English as a second (or third, or ...) language and now have better English communication skills than I do, so native English speaker/English as a first language might benefit from rephrasing, if the thought survives. (**) My Chinese co-workers can conjure up 5000 years of rich idioms, and I enjoy hearing them, but they don't seem to translate them into English and insert them into conversations nearly as often as I insert idioms into conversations ...
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
On 9/3/2013 3:49 PM, Bradner, Scott wrote: in line On Sep 3, 2013, at 4:45 PM, Pete Resnick presn...@qti.qualcomm.com wrote: at it - maybe you should remove the 2nd paragraph in the same section An official summary of standards actions completed and pending shall appear in each issue of the Internet Society's newsletter. This shall constitute the publication of record for Internet standards actions. should also be removed since that is not being done either and it is not good to say we have a publication of record that does not actually exist I agree it should probably be removed. Should we replace it anything? Maybe an informational statement that the current standards status is always at http://www.rfc-editor.org/rfcxx00.html ? (Or whatever stable URL the RFC Editor prefers to cite.) I've fixed the reference to [STDS-TRK] so that it shows the URL. I'm not sure we need to make further reference to it. Thinking about this more, we're starting to drift afield of the purpose of this document if we start removing that paragraph. Removing that paragraph requires a different explanation than the rest. Speaking for myself only, I'm leaning against dealing with it. Anyone want to speak strongly for or against? I agree that the explanation is different, but I go back to Scott's it is not good to say we have a publication of record that does not actually exist. Not that Pete and I get paid by the document on telechat agendas, but is this another candidate for a short draft? Spencer
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
On 9/3/2013 6:02 PM, Pete Resnick wrote: On 9/3/13 3:17 PM, Brian E Carpenter wrote: rant class=shortSo that the reader of RFC 2026 will need to read yet another document to get the full picture? There are currently 8 RFCs that update RFC 2026, some of which have been updated themselves./rant Quite seriously - I appreciate Pete's reluctance to overload the draft, but it is a related topic. I'd be inclined to include it. OK, does this do anything for anyone? Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the publication of an official summary of standards actions completed and pending in the Internet Society's newsletter. This has also not been done in recent years, and the publication of record for standards actions has for some time been the minutes of the IESG. [IESG-MINUTES] Therefore, that paragraph is also effectively removed from section 6.1.3. That would work for me. Spencer
Re: [87attendees] procedural question with remote participation
On Monday, August 5, 2013, Aaron Yi DING wrote: On 05/08/13 10:38, Scott Brim wrote: Right, but Fuyou was talking about *spoken* English being more challenging than written English (if you can't *read* English fairly quickly, drafts and mailing lists are impenetrable, and you're done in the IETF). I'm told that it's easier for non-native English speakers to read slides than to parse spoken English for anyone who talks faster than I do. don't forget there are accents as well which make the parsing challenging even more challenging. When I have talked to non-native English speakers at the IETF newcomers tutorial, pointing out that many of the speakers they're working to understand are also not not native English speakers often turns out to be encouraging. ...
Re: procedural question with remote participation
On 8/4/2013 3:10 PM, Hadriel Kaplan wrote: OK, I'll bite. Why do you and Michael believe you need to have the slides 1 week in advance? You have the agenda and drafts 2 weeks in advance. The slides aren't normative. Even when they're not about a draft in particular, the slides are not self-standing documents. They're merely to help with discussion. Not getting the slides at all is a different matter - but 7 days in advance is counter-productive. They should be as up-to-date as practical, to take into account mailing list discussions. [or at least that's how I justify my same-day, ultra-fresh slides] If you need to have them on the website 7 days in advance, you really need to get a faster Internet connection. ;) I'm a TSV AD, but I'm sending this note wearing no hat (someone last week asked me why I wasn't wearing a cowboy hat if I was from Texas - no, not even a cowboy hat). I read through the discussion on this, and I'm only responding to Hadriel because his post was the last one I saw before replying. Thank you all for sharing your thoughts. YMMV (Your Mileage May Vary), but I have been sponsored for several years by a company that sends a sizable number of folks to IETF who are not native English speakers. Having slides early helps non-native English speakers (I believe I've heard that some slide decks are translated into other languages, although I wouldn't know, because I read the slides in English). After his first IETF (Paris/63), Fuyou Maio said to me, understanding spoken English is the short board in the water barrel (the idea being that your effectiveness at the IETF is limited by your ability to quickly parse spoken English). The folks I talk to get plenty of chances to translate spoken English during QA, and don't need additional practice translating the presentations in real time. Yes, I know people say things that aren't on their slides, but if what's on their slides doesn't help other people understand what they are saying, they probably shouldn't be using those slides. In the mid-2000s, I remember an admonition for chairs to write out the questions the chairs are taking a hum on, to accommodate non-native English speakers (and to write out all the questions before taking the first hum, to accommodate anyone who agrees with the second choice but prefer the fourth choice when they hear it after humming). I'm having a hard time making the a week early or you don't present case for slide cutoffs, because we DO talk during the meeting week - and in groups RTCWeb, with a Thursday slot and a Friday slot, we had time to talk a lot. If the cutoff was for presentations of new individual drafts, that's a different question, so there might be some way to make non-Procrustean improvements(*). I agree with the chairs looking at slides for sanity point. I'm remembering more than one working group where we chairs got presentations that included about a slide per minute for the time allocated to the topic - noticing that even one day before saved us from the ever-popular we can't talk about this presentation because we don't have time moment. During IETF 87, I had reason to consult the proceedings for the non-workgroup-forming RUTS BOF (Requirements for Unicast Transport/Sessions at IETF 43, minutes at http://www.ietf.org/proceedings/43/43rd-ietf-98dec-142.html#TopOfPage) http://www.ietf.org/proceedings/43/43rd-ietf-98dec-142.html#TopOfPage. This was the applications-focused wishlist for transport from 1998, when COPS, RADIUS, L2TP, HTTP-NG, SIP, NFSv4, SS7, IP Telephony and BGP4 were all trying to figure out whether they needed to (continue to, in some cases) rely on TCP for transport, or do something else. I'm remembering that there were slides, and I would love to have them to refer to, but *none* of the slide decks made it into the proceedings. That was pre-Meeting Materials page, but even my experience with the Meeting Materials page was that it's easier for slide decks arriving late to go missing than for slide decks that arrived early. As I reminded myself while starting to present v4 of the chair slides in TSVAREA and realizing that what Martin was projecting was v1 (only a day older), getting slidesets nailed down early limits the number of times when you're surprised at what's being projected. I love consolidated slide decks. I bet anyone does, whose laptop blue-screened while hooking up to a projector in the late 1990s. Nothing good happens during transitions, whether switching laptops or switching presentations :-) None of this should be taken as disagreement with proposals to experiment with room shapes, whiteboards, , etc. that I heard last week. None of this should be taken as evidence of love for an unbroken stream of presentations of drafts that aren't tied to issues discussed on mailing lists, or as disagreement with the idea that presentations aren't always the best way to communicate at the
Re: procedural question with remote participation
On 8/4/2013 8:36 PM, Hadriel Kaplan wrote: Regarding the need for presentations early to get them translated, and the non-Procrustean[1] improvement of having cutoffs for presentations of new drafts: new drafts are still submitted 2 weeks in advance, and ISTM that a real non-Procrustean tactic would be to let the WG chairs do their jobs. If you've got a 40 page slide-deck chock full of text, giving a detailed tutorial on some mechanism, it's a different situation from the norm. (and I'd argue you're probably doing it wrong, but ymmv) But those appear to be the exceptions, not the rule; and WG chairs can handle push-back for exceptions if they need to. We don't have to create new draconian rules. Oh, I wouldn't dream of having rules about that. What I was trying to say in my not-enough-sleep-last-week way was that I was imagining so many justifiable exceptions (chair slides, on-the-fly hums, reports from design teams and hallway conversations the day before) that having rules wouldn't help, so, agreed. But for the general case, the truth is that Fuyou Maio is right - you really do need to be able to parse English quickly to truly participate effectively in an IETF physical meeting. And you need to be reasonably swift in either reading it, or following the speaker's words. It's not nice to say, but it's the truth. Real-time direct human communication is why we have the physical meetings to begin with, instead of only mailing lists and virtual meetings. (and for cross-wg-pollination, and for cookies) Right, but Fuyou was talking about *spoken* English being more challenging than written English (if you can't *read* English fairly quickly, drafts and mailing lists are impenetrable, and you're done in the IETF). I'm told that it's easier for non-native English speakers to read slides than to parse spoken English for anyone who talks faster than I do. I'm not saying that should override other considerations. I was responding to a question several people asked, if anyone would benefit from having slides early (for the purposes of this e-mail, 24 hours early would be plenty early enough). Other people provided other answers, and I hadn't seen that answer go past. Thanks, Spencer p.s. I DID footnote Procrustean with a definition, but that's perfectly reasonable to point to as not helpful for non-native English speakers - please feel free to keep me relatively honest.
Re: Final Announcement of Qualified Volunteers
On 7/9/2013 8:59 AM, Scott Brim wrote: The sample is better at 140 if individuals represent themselves, but not if they are swayed by their organizational affiliation, and organization is now a significant factor in what we can expect from volunteers -- not all, but even some of those from organizations where the volunteers are long time participants. I support this idea. I think the gain is greater than the loss, and it even fosters diversity. I don't have a lot of time to chat about this, but - I agree with Scott that it matters what voting members are guided by (organization, personal experience, intuition, flipping coins ...) - I suspect that it's not possible to predict what any 10 voting members chosen at random will be guided by - I'm not sure we can even know what the 10 voting members *were* guided by, unless the behavior is so bad that the advisor freaks out or the chair tells us in the plenary Nomcom report If people want to think about the Nomcom volunteer pool, it may be useful to wonder about whether the perspective of voting members from more organizations would help the Nomcom make better choices. Of course, I'm not sure we can predict that, either :-) Spencer
Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
On 6/6/2013 8:12 AM, Stephen Farrell wrote: - 3.3.1.4 says: Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted. That's a pretty bogus setup. I would think that if IEEE do want to share some or all drafts with us they could much more easily create a web page when those drafts are available without access control. Or we could if they didn't mind. (Or I could do it if there's no we that wants to:-) Asking IETF WG chairs to deal with passwords is a bit silly. I'm not objecting to this, but am suggesting someone ask IEEE if they'd like to consider the silliness here and fix it. Hi, Stephen, It's probably worth pointing out to the community that both IETF and IEEE 802 leadership have been looking at previous revisions and asking if they do that, should we do the same? The most recent case I can think of was that IETF published a list of its liaison managers, while IEEE 802 did not - but review discussions prompted iEEE 802 to start publishing a list of its liaison managers as well. There have been others. I'd be pleasantly surprised if either organization has run out of bogosity to fix, of course ;-) Spencer
Hands across the water/hands across the sky
For those of you looking at where I-D and RFC authors are from, I'd like to suggest one other thing to look at - the extent that participants are co-authoring with folks outside their region. It's pretty tempting for new participants to submit drafts that they like, and maybe reaching out to their office mates as co-authors, but to be effective in the IETF, participants have to learn how to collaborate with folks from other IETF sponsors (including other IETF sponsors who compete head-to-head with your IETF sponsor), other countries, and other regions. Collaboration covers many activities, but I'm curious what we might learn from looking at this specific kind of collaboration. personal self-reveal I say this to a lot of people who don't believe me, but I have been shy for most of my life, and it's still not easy for me to have conversations with total strangers. That's not a cultural challenge, and it's not a language challenge, but it is a challenge I've faced in the IETF as *I* was learning to collaborate. For anyone who is also learning how to do this - for me, it's been worth it. And anyone is welcome to join us for drumming at IETF meetings - I bring extra drums, and there's no telling who else you'll meet. /personal self-reveal Thanks, Spencer p.s. I apologize for the obscure reference in the Subject line to Paul Linda McCartney's Uncle Albert / Admiral Halsey - it's from about 2:30 into http://www.youtube.com/watch?v=XI6C7L66zq8.
Re: When to adopt a WG I-D
On 5/28/2013 10:22 AM, Joel M. Halpern wrote: In reading through the draft, particularly the section on questions for WG adoption of a draft, I did not see the questions I consider most pertinent: I appreciate Dave and Adrian for producing this helpful start, and I'm mostly comfortable with where this conversation has gone since Adrian asked for feedback on this list. I wanted specifically to echo Joel's suggestions for additional questions. Does the WG think this is a reasonable (preferably good) basis for starting to work collectively on the deliverable? I read this as is this stable enough for a working group to work on it, or might we still want to tell some small number of people to go off in a corner and try again to produce something that IS a reasonable basis? I agree. To the extent that a working group really does control the contents of a working group draft, if the working group doesn't agree that the draft is a reasonable basis, making consensus calls about massive rewrites seems more painful than we are hoping for. Another question many WGs have found useful is: Are there enough people interested and willing to write and / or review the document? Exactly. We should work on working group drafts. If a working group doesn't have the resources and willingness to work on the document, I'm not sure how much sense it makes to adopt it as a draft that's being officially ignored by the working group :-) Spencer
Re: call for ideas: tail-heavy IETF process
On 5/8/2013 10:50 AM, Jari Arkko wrote: Heather, all, You are correct, Peter. MISSREF and AUTH48 are not part of the RFC Editor timed states, and the RFC Editor timed states have been largely under 7 weeks for the last year. Indeed. The actual time for what RFC Editor does for documents is quite short (and thank you and others at the RFC Editor side for that!). My stats counted both MISSREF and AUTH48, I think. I remember that when this was previously discussed (mid-2000s), we noted that the states didn't map 1:1 with who had to actually do something. Sounds like this is still true. So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... Spencer
Re: Meritocracy, diversity, and leaning on the people you know
On 4/19/2013 1:47 PM, Dave Cridland wrote: Nice post. I wonder whether a better mechanism for drawing newcomers into the inner circle - which is what I think you're intent is here - would be to randomly select people to be involved in a short online meeting to discuss the draft, rather than review it in isolation. It'd be a different kind of review, which adds value for us, I think, and would instantiate new human subnets which could be used to bootstrap other involvement. This is, I stress, merely a quick reaction to your much more thoughtful post, and I reserve the right to backtrack and change my mind. I'm replying to Dave's note, but read further through the thread. I'm not seeing the randomly-invite-to-review and randomly-invite-to-discuss being mutually exclusive. If I'm reading the mail threads on newcomer assimilation correctly, what we're hoping for is to identify people who we might not always identify, who can and will produce good work. The additional random selection gives people who we might not have identified a chance to show whether they can and will produce good work. I note that one of these possibilities places more emphasis on spoken English than the other. That's important to keep in mind. Maybe letting people self-select for the kind of review is helpful. Thanks, Spencer
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 12:49 AM, SM wrote: At 13:46 11-04-2013, Spencer Dawkins wrote: If the IAB means members, the number for females, as far as I know(*), is 2/15, or 13 percent. If it means voting members, the number for females is 1/13, or just under 8 percent. If I use the 13% I can say that the IAB is more diverse than the IAOC. Some organizations use political arithmetic to look good. Hi, SM, I was just checking the math. I couldn't possibly say what good means, and I'm interested in better understanding what diverse means, to this, ummm, at least somewhat diverse community ... Spencer p.s. And I wasn't trying to be snarky about the math. I blew the percentages in the first draft of my response, so I know it happens to the best of us :-)
Re: IETF Diversity Question on Berlin Registration?
On 4/12/2013 8:51 PM, Ted Lemon wrote: On Apr 12, 2013, at 7:32 PM, SM s...@resistor.net wrote: Thomas Narten mentioned that: we have the tendency to pick the people we know and trust, which is understandable. How many IAB members feel strongly about open standards, rough consensus and running code? To know the answer I would have to actually know the IAB members. Are they really that hard to get to know? A number of them are participating in this conversation. It's certainly hard to get time to sit with them at IETF meetings. I don't know what the workload is like for IAB members, but I think I worked at least an 80 hour week in Orlando. So, I can only answer for one IAB member ... I'm less busy during IETF weeks than most IESG members. It happens that SM grabbed me for at least one extended conversation in the hallway in Orlando (he grabbed me for several conversations, but not all of them lasted half an hour), and I found that conversation very helpful from my side. Again, for myself - I see my role as an IAB member to be as helpful as I can be, so answering questions is something I do, and I need to do more often. There are places I have to be, during IETF weeks - for instance, we were interviewing ISOC Board of Trustee nominees at specific times - but there are places I'm going that I don't have to get to, if someone needs to talk with me. Finally - there are people on the IAB with fabulous social skills, but I'm not one of them. If someone needs to spend time picking my brain, I usually do have multiple meals open during IETF week. Spencer
Re: IETF Diversity Question on Berlin Registration?
On 4/11/2013 3:09 PM, Yoav Nir wrote: Dave Crocker suggested getting an expert. I don't think that would help. Such an expert would tell you that the questions you can ask depends on the group you are asking. Questions that would be acceptable in one country, would be inappropriate in another. In Israel people are likely to answer sensitive questions truthfully, while in Germany concern for privacy might make these questions seem too personal. So how do you fit such a questionnaire to a, well, diverse group such as meeting attendants? OK, are you proposing an anonymous survey, unrelated to registration? Thanks, Spencer
Re: IETF Diversity Question on Berlin Registration?
Hi, SM, This may be a misprint ... On 4/11/2013 3:21 PM, Ted Lemon wrote: On Apr 11, 2013, at 3:43 PM, SM s...@resistor.net wrote: 12.5 % of IAOC voting members are female. 0.1% of IAB members are female 0 % of IESG members are female. Based on the above measurements the IAOC is more diverse. The IAOC already collects gender-related information. The other information requested in the meeting registration form is strictly for meeting attendance purposes. The sensitive questions referred to above have nothing to do with meeting attendance. With respect, this is sampling noise. 12.5% of 8 is 1. Don't get me wrong—it's great that we have some diversity on the IAOC, but I don't think anybody should be patting themselves on the back just yet! What diversity is the IAOC measuring? By my count, the current IAB membership is 15 (12 Nomcom-selected, plus the IETF chair, plus the ExecDir, plus the IRTF Chair - these last two are ex-officio and non-voting). If the IAB means members, the number for females, as far as I know(*), is 2/15, or 13 percent. If it means voting members, the number for females is 1/13, or just under 8 percent. Other diversities also matter, and I'm just doing math here (**). Spencer (*) In my spare time, I'm co-president of PFLAG Dallas, which is a local chapter of PFLAG, an abbreviated abbreviation of Parents, Families and Friends of Lesbian, Gay, Bisexual _and Transgender_ people, so I know I can't claim definitive knowledge on who's what ... only on what people appear to be. (**) I think diversity matters, and didn't want us to look less gender-diverse than we are ...
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
On 4/5/2013 9:09 AM, Steve Crocker wrote:
I too have always found at least one of the Crocker brothers {suspicious,
smart, funny, irrelevant, prescient, handsome, annoying, etc.}. I've never been
able to tell which is which :)
There are days when I'm really glad to be part of this community ...
Spencer
Re: Diversity of IETF Leadership
I'm somewhat worried at the lurch this thread has taken into the land of protected classes, legal advice, etc. I hope we do not go there. Having said that ... since Eric asked ... On 3/20/2013 9:57 AM, Eric Burger wrote: Going a bit over-the-top: is there an interaction between sex and sexual orientation? Can one count as the other? I'm not answering as an IAB member, but as co-president of PFLAG Dallas (Parents, Families and Friends of Lesbians, Gays, Bisexuals and Transgenders) ... PFLAG includes sexual orientation under sexual orientation, gender identity and expression. Each of these terms means something different, and all of these can be distinct from birth gender. So, PFLAG would suggest that we treat gender and sexual orientation, gender identity and expression interchangeably. Spencer (www.pflag.org)
Re: Diversity of IETF Leadership
On 3/20/2013 11:21 AM, Mary Barnes wrote: On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore mo...@network-heretics.com wrote: So I guess I've formed the impression that merely being nominated for a position doesn't really mean that a person is available. [MB] You have to keep in mind in the past that the there were dummies in the nominee pool before open list. I was explicitly told by this year's nomcom chair that they were not doing that. Thus, I would anticipate that the majority of those in the pool this year were willing and able.[/MB] Both of you are right, of course. Before OpenList, the list of nominees willing to be considered was treated as confidential. Nomcoms that wanted to ask for input on specific people sent out lists of nominees that were padded, as Keith says, so that there were dummies (usually described as ringers), and theoretically no one outside Nomcom knew precisely who was being considered. When we approved http://www.rfc-editor.org/rfc/rfc5680.txt in 2009, it added this text to RFC 3777: The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The list of nominees disclosed for a specific position should contain only the names of nominees who are willing to be considered for the position under review. The NomCom may choose not to include some names in the disclosed list, at their discretion. The NomCom may disclose an updated list, at their discretion. For example, the NomCom might disclose an updated list if the NomCom identifies errors/omissions in a previously disclosed version of the disclosed list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to be considered before the NomCom has completed its deliberations. Nominees may choose to ask people to provide feedback to the NomCom, but should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior. IETF community members are encouraged to provide feedback on nominees to the NomCom, but should not post statements of support/ non-support for nominees in any public forum. So, the assumption before 2009 was that lists were padded, and the assumption after 2009 is that lists aren't padded. The Nomcom can do what seems right, of course. Spencer
Re: Getting rid of the dot
On 3/19/2013 4:09 PM, Scott Brim wrote: It costs a lot more to get lanyards that attach at two corners. Why am I encouraged every time I come across a problem that can be solved with duct tape? :-) Spencer
Re: Mentoring
On 3/19/2013 8:01 PM, Ben Campbell wrote: I think this means we should closely consider the goals of a mentoring effort. Is it to help them navigate the IETF structure, personalities, and immune system to get something done? Is it to help them become the next generation of IETF leaders? I suspect those two goals do not lend themselves to the same approach. Yeah, I agree with Ben here. I'd go further and suggest that helping people get something done is a good thing, and at least some of the people who have gotten something done are more likely to to hang around, but if people want to be part of the next generation of IETF leadership without actually getting something done first, encouraging them may not take the IETF to a happy place. Spencer
Re: meetecho praise
What Mary said, especially from a chair perspective. I stepped down as co-chair of three working groups just as the Meetecho team reached cruising speed, but they were very active in MediaCtrl and we benefited considerably from using an early version in Hiroshima. If I was co-chairing three working groups today, I would already have sent them my request for support in Berlin :-) Thanks, guys, for all that you do! Spencer On 3/18/2013 10:39 AM, Mary Barnes wrote: On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Hello. I would just like to say I'm very grateful for the WGs that used Meetecho to record their sessions. The HTML5 versions works out of the box with no plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7 machine. The sync of sound, slides, picture and jabber room is excellent and makes it very easy top follow what's going on. Some other recordings focus too much on the video of the speaker, where I'm of the opinion that it's the slides and the sound that is most important, and current incarnation of Meetecho solves this very nicely. I applaud these efforts and hope we can end up in a situation where all meetings at the IETF is recorded in this way. [MB] That would be wonderful. I find Meetecho fantastic for going back and re-reviewing the meeting in cases where notes aren't complete. As a chair, it's really hard to take good notes and it's sometimes hard for participants as they are sometimes to engage in discussions. The Meetecho team works extremely hard during these meetings and definitely deserve applause for their work. [/MB] Thanks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Mentoring
On 3/18/2013 2:34 PM, Arturo Servin wrote: Yes and no. I would get rid of all the dots, possible yes. In general, I like the scope of what's being questioned in the past week or so, even if the answer comes back we talked about this, and the other stuff we could think of was worse :-) On dots, specifically ... I'm guessing from context that you're thinking red/IAB, yellow/IESG, blue/WG chairs, and possibly pink (technically the IRSG, but almost all the IRSG members are also RG chairs, so in this case, pink is like yellow and blue, mixed together). There are dots, and then there are dots. The one I'd like to see continued the most is the orange dot, for Nomcom members. We choose the voting members at random out of a volunteer pool, with some qualifications but not a lot, for a specific duration. Perhaps there's value in helping the community identify Nomcom members quickly during breaks, etc. For several years, I've scheduled meetings with Nomcom during their office hours, but I'm usually providing input on 10-20 willing nominees. It might be helpful for someone to chat with a Nomcom member and give feedback on one or two willing nominees in just a few minutes - that's what I'm talking about. If the IAOC continues to hold open sessions at future IETF meetings, that's good; if not, perhaps there's value in helping the community identify IAOC members quickly, too. For extra credit, picking a color that's easier to identify distinctly would help (I can't consistently tell the difference between purple/IAOC member and blue/WG Chair unless someone is wearing both). IIRC, the green Local Host dots were intended to help people who weren't familiar with a meeting site find someone who was familiar with that site. Now that we have an IAOC, and attendees lists and meeting wikis, and a larger and more visible secretariat, green dots may have more value as recognition for meeting sponsors (and if giving out green dots matters to people who support the IETF financially, that's certainly sufficient as a reason to keep them!). Just keep thinking carefully, as people are doing, and developing a better understanding about what we are doing and why it might have been our practice in the past ... and whether it's still a good idea now. Thanks, Spencer The new attendee tag, not sure. May change it for a dot. The tags is useful to identify new people and help. A mentor tag or dot would be useful to people for not thinking that you are a weirdo trying to make conversation. We need to get rid of old traditions if they do not longer apply, but also we need to subtle identify people willing to help and people that may need some help. Regards, as On 3/18/13 3:14 PM, SM wrote: I would get rid of the dots. It seems that the IETF has been perpetuating rituals for no reason other than it is tradition (it is how things were done before). I would get rid of the new attendee tag as it creates different categories of individuals.
Re: Getting rid of the dot
On 3/18/2013 5:04 PM, SM wrote: At 13:49 18-03-2013, Spencer Dawkins wrote: There are dots, and then there are dots. The one I'd like to see continued the most is the orange dot, for Nomcom members. We choose the voting members at random out of a volunteer pool, with some qualifications but not a lot, for a specific duration. Perhaps there's value in helping the community identify Nomcom members quickly during breaks, etc. Did you need to look for the NomCom dot to identify NomCom members? :-) Hi, SM, Not me, even when I don't recognize half the names of voting members, because I identify NomCom members by sending a request for an interview slot (and I'm remembering that these are 30 minutes long), so everyone in the room when I arrive is a NomCom member ;-) That's OK for people who can provide input on lots of people - I do - but doesn't scale for people who just want to provide input on a couple of people they've worked with, who are willing nominees for a NomCom-selected position. Grabbing someone who has to listen because they're chewing a cookie can be enough, sometimes! Spencer
Re: Mentoring
On 3/14/2013 7:30 AM, Adrian Farrel wrote: Mary, I need to check but... [MB] What I find interesting is that there was 200+ newcomers, but I certainly didn't find that many at the meet and greet. I have to wonder whether this doesn't have to do with the overlap between Sunday tutorials and this event. I think that needs to be fixed. Very right that it would need to be fixed, but I thought that it was avoided explicitly and deliberately. Anyone got a copy of the agenda in front of them? The second slot for tutorials is listed as 1500-1650. The newcomer's gig is listed as 1600-1700. So, conflicting. Maybe we could do a little research on why newcomers don't show at this meeting. Are they tired? Shy? Unaware? Not perceiving the value? I've been supported by an IETF sponsor who has sent a heck of a lot of new attendees to the IETF since 2005. One point that's come up repeatedly is that people show up on Sunday afternoon and evening because the real IETF meeting starts Monday morning. Some of the newcomers are likely still at the airport during the newcomer's meet and greet. Spencer
Re: Mentoring
On 3/14/2013 7:53 AM, John C Klensin wrote: (2) Our newcomers model doesn't distinguish likely long-term participants from tourists. I think we should be welcoming to the tourists but, in terms of, e.g., scarce mentoring resources, spending time on them is a bad optimization. In addition newcomer is really not a one-shot thing. I don't know how to identify and create a ribbon distinction between newcomer and possible long-term participant and tourist and it is probably impractical, but a ribbon in a different color for second-time attendees might be helpful. If we have (at this meeting) potentially 800 people trying to help 200 people engage, that's still a tall order. Ack. As was said last night, if someone wearing a newcomer badge seems to be either lost or isolated, approaching them is usually A Good Thing. And that principle should apply for two or three meetings, not just one. I wonder if the target audience for SOMEthing might be two-comers - people at their SECOND meeting. Spencer
Re: Mentoring
On 3/14/2013 3:07 PM, Michael Richardson wrote: As to the newcomer meet and greet... I actually think we got it a bit backwards. I think that WG chairs should be uninvited. (as much as I like free beer). Rather, I think that the newcomer meet and greet (and free beer) should follow the newcomer orientation session. Instead, I think that newcomers need to meet other newcomers. If they are going to meet with a mentor/greeter person, then a slot just before the reception would be good... I'd say just open the reception doors to newcomers and the mentors 20 minutes early. Wait ... did I understand that you're offering MENTORS free beer before everyone (except the newcomers) gets in? If so, I congratulate you for solving the problem of recruiting mentors! This will be the biggest disruption in the world of Internet protocols since they turned off NCP on Flag Day :p Spencer
Re: Consensus on the responsibility for qualifications? (Was: Re: Nomcom is responsible for IESG qualifications)
On 3/13/2013 1:45 PM, Melinda Shore wrote: On 3/13/2013 10:27 AM, Dave Crocker wrote: 4. Nomcom makes its own decision about the criteria it will use for selecting nominees; as such, it really is defining the /actual/ requirements for positions. I think we need to acknowledge that the confirming body (IAB) effectively has veto power over those criteria/requirements, since it can reject candidates who were selected by evaluation against those criteria. Well, for what it's worth ... people willing to be considered would probably like to know what the description Nomcom uses really is, and so would people being asked to comment on willing nominees. As a member of one of the confirming bodies, I would like to know what Nomcom thinks the description is, when I'm considering candidates to confirm. Spencer p.s. For the brave souls who are still reading - my understanding of the process is that Nomcoms ask for feedback on willing nominees, and then get feedback on what the description should be as part of feedback on nominees. If you think nominees read position descriptions, Nomcoms might end up with willing nominees that more closely match the position description if the Nomcom collects feedback on the position description before providing it as part of a call for nominations. I'm not suggesting two calls for feedback (one on the descriptions/needs of the position, and one on the willing nominees). But how you give potential nominees a the description they'll be considered against, without asking the community for feedback and then deciding what the position description is, and then asking for nominations, I couldn't say.
Re: Martians
On 3/12/2013 1:45 PM, John C Klensin wrote: In any event, I've gotten some feedback that some people thought I was identifying them as Martians and were offended. No offense was intended and I used the Martian terminology precisely to avoid that possibility. I obviously failed and apologize to anyone who didn't hear or understand what I was trying to say in the way I intended to say it. I'll try to watch my choice of vocabulary even more in the future. At least some of the nerdier nerds were probably thinking how could *I* become a Martian? because that would be so cool! ... But just to your point that this wasn't about native English speakers ... Doesn't Alfred HÎnes still have the indoor record for accepted RFC editorial(*) errata in the history of, like, ever? :) Spencer (*) and non-editorial errata, too, but that's a different story ...
Re: Diversity of IETF Leadership
On 3/11/2013 11:41 AM, Fred Baker (fred) wrote: On Mar 10, 2013, at 1:57 PM, Spencer Dawkins spen...@wonderhamster.org wrote: On 3/10/2013 5:22 AM, IETF Diversity wrote: I'm listed as a signatory and agree that this is important. There are several steps that could be taken, in the short-term within our existing BCPs, to address this problem: - Each of the confirming bodies (the ISOC Board for the IAB, the IAB for the IESG, and the IESG for the IAOC) could make a public statement at the beginning of each year's nominations process that they will not confirm a slate unless it contributes to increased diversity within the IETF leadership, or it is accompanied by a detailed explanation of what steps were taken to select a more diverse slate and why it was not possible to do so. I'd ask that people think about what the confirming bodies should be willing to say, along these lines. It seems a bit strong to me, but I'm not sure what the community is comfortable with. Personally, I'm uncomfortable with the above statement. Yes, diversity is a good thing, and I'm all for it. However, I don't think it is a fundamental goal; the fundamental goal is (as Jari said) to get the best people for the job from the available talent pool. I don't know that political correctness automatically helps there. Hi, Fred, I'm not sure which above statement you're uncomfortable with - my original e-mail was saying that I was uncomfortable with the proposed actions for the confirming bodies, and was asking if there were any other actions that might make sense for the confirming bodies to take. One possible answer is no. Another possible answer is not yet. I've seen both of those go past in this thread. I'm just if there are other possible answers. For the noncom, if there is a choice between two people of equal capability, diversity considerations can be useful in selection (pick the person who is not a north american or european white male). But when it comes to confirmation of a slate, the confirming body is not being asked whether there are enough little green women, it's being asked whether the individuals selected and the resulting committees (the IAB, the IESG, or whatever) will be effective and competent in the role. A statement like Send us more little green women from a confirming body to the noncom makes some important assumptions: that there were little green women to choose from, that they were equally or more competent than the person selected, and so on. The confirming body is not privy to the discussions of the noncom, and isn't told why a given individual was not selected, only the arguments for those selected. That makes all such assumptions pretty dubious. Agreed. I'd prefer that confirmation processes stick to fundamental goals, not political correctness. If you want to encourage the noncom to consider diversity in its deliberations, fine. But not the confirming bodies. I'm listening - thanks for sharing your thoughts. Spencer
Re: Diversity of IETF Leadership
On 3/11/2013 1:03 PM, Keith Moore wrote: On 03/11/2013 01:43 PM, Arturo Servin wrote: My opinion is that we agree we have a situation that we should improve, but also we shouldn't focus on the nomcom process, the problem is not about how we select people (it may help but it is not the root problem). The problem is to bring new people (younger people, women, from more countries, different languages, etc.) to write RFCs, to participate/be interested in the IETF and how we involve/prepare these people to become our leaders and not just participants. If we do that, then we will have more diversity in our leadership. Agree. And I suspect that a large part of the answer is make effective participation in IETF substantially less expensive than it is now (I didn't say it was an easy problem to solve.) Keith Arturo and Keith, Thank you both for these thoughts. I've self-funded a couple of IETF meetings, but still think primarily about expensive in terms of time. Spencer
Re: Diversity of IETF Leadership
On 3/10/2013 5:22 AM, IETF Diversity wrote: I'm listed as a signatory and agree that this is important. There are several steps that could be taken, in the short-term within our existing BCPs, to address this problem: - Each of the confirming bodies (the ISOC Board for the IAB, the IAB for the IESG, and the IESG for the IAOC) could make a public statement at the beginning of each year's nominations process that they will not confirm a slate unless it contributes to increased diversity within the IETF leadership, or it is accompanied by a detailed explanation of what steps were taken to select a more diverse slate and why it was not possible to do so. I'd ask that people think about what the confirming bodies should be willing to say, along these lines. It seems a bit strong to me, but I'm not sure what the community is comfortable with. Thanks, Spencer (In alphabetical order) Spencer Dawkins
Re: Diversity of IETF Leadership
On 3/10/2013 2:50 PM, Scott Brim wrote: On 03/10/13 15:43, John Levine allegedly wrote: - Each of the confirming bodies (the ISOC Board for the IAB, the IAB for the IESG, and the IESG for the IAOC) could make a public statement at the beginning of each year's nominations process that they will not confirm a slate unless it contributes to increased diversity within the IETF leadership, or it is accompanied by a detailed explanation of what steps were taken to select a more diverse slate and why it was not possible to do so. That sounds a lot like quotas. Let's not go there. +1. We do not want to manage by ideology - consider how well that serves political parties. Right. So is there anything you would like for the confirming bodies to say to Nomcom, that doesn't sound like quotas? Spencer
Re: Diversity of IETF Leadership
For what it's worth, On 3/10/2013 5:45 PM, Melinda Shore wrote: On 3/10/2013 1:04 PM, Spencer Dawkins wrote: +1. We do not want to manage by ideology - consider how well that serves political parties. Right. My right here was in the context of the snipped line above +1, which was That sounds a lot like quotas. Let's not go there. Well, I don't know. To be honest The I* should contain more than one sort of human doesn't sound *that* ideological to me. It doesn't sound *that* ideological to me, either. My question was So is there anything you would like for the confirming bodies to say to Nomcom, that doesn't sound like quotas? So far, I've seen an observation that confirming bodies inserting themselves into the process of achieving a more diverse I* may be premature (quoting Randall, I wonder if such a step might be better kept in reserve if other steps don't work? Especially because one of the later proposals is to better understand the causes of lack of diversity in the I* and specific measures to increase diversity? It might be better to take that step before this one). That makes some sense to me. What am I missing? Thank you, Spencer
Re: Diversity of IETF Leadership
On 3/10/2013 9:08 PM, Melinda Shore wrote: Do you feel that what's described in the letter is an accurate and complete description of the/a problem? Well, sure. I signed it, right? :D I have some heartburn about the paragraph on the confirming bodies in the short-term, within-BCPs section, but I signed it because I agreed with the problem statement. Spencer
What anyone can read about recent Nomcoms
I posted a couple of links to detailed Nomcom reports from Mary (2009-2010) and Joel (2008-2009) yesterday - they're available at http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00 and http://tools.ietf.org/html/draft-halpern-nomcom-report-00 Mike provided a pointer to Lakshminath's detailed Nomcom report (2007-2008) to me in private e-mail yesterday (it's available at https://wiki.tools.ietf.org/group/nomcom/07/nomcom-report). All of these reports were presented to the community at the meetings where the new slates were seated, so they aren't considered confidential, and they could be helpful for people who are thinking about Nomcom now, but haven't served on a recent Nomcom. Thanks, Spencer p.s. Those are the only detailed reports Mike and I know about. Other Nomcom chairs have provided a high-level reports at plenary meetings (for example, http://www.ietf.org/proceedings/83/slides/slides-83-iesg-9-ietf-operations-and-administration-plenary.pdf from Suresh, for last year's Nomcom, or http://www.ietf.org/proceedings/80/slides/plenaryw-9.pdf from Tom's Nomcom). I appreciate these high-level reports as well, of course.
Re: Nomcom is responsible for IESG qualifications
On 3/7/2013 5:01 PM, Ted Hardie wrote: On Thu, Mar 7, 2013 at 1:56 PM, Joel M. Halpern j...@joelhalpern.com wrote: One of the interesting things is that the nomcom does not in practice have a way to tell the community exactly what it decided the job requirements are. Why is the Nomcom report not a mechanism to do this? Ted, I just sent Joel a note about this privately, but since you mention it ... I think part of the reason may be that if there's a gap between the job description that the willing nominees saw before they said they were willing to be considered and the job description that the Nomcom actually used, you might not end up with the same willing nominees in both cases. (*) So the Nomcom report at the first IETF meeting of the year would be a good place to talk about what got changed, but too late for nominees who were a better match for the Nomcom's description than the initial description to agree to be considered. Thanks, Spencer (**) (*) Ideally, you end up with better willing nominees if they know the description Nomcom will be using (**) I've been on one Nomcom as IAB liaison, and never as a voting member
Re: Nomcom is responsible for IESG qualifications
On 3/7/2013 6:54 PM, Mary Barnes wrote: [MB] Personally, I don't think the .ppts at the plenary should be the only Nomcom report. It's really hard to tease things out from bullet points. Per my earlier note, I believe the community should expect that the nomcom chair produce a written report in a form similar to what had been done previously - e.g., 2009-2010 and 2008-2009 were the last two I am aware of. That would allow the community to read the report and discuss things rather than make assumptions about bullet points during a live meeting. [/MB] Mary, I agree. I'd like to see a return to http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00 and http://tools.ietf.org/html/draft-halpern-nomcom-report-00 (especially since both of these reports talked about issues we encountered this Nomcom cycle :-) Spencer
Re: Nomcom off in the wilderness: Transport AD
On 3/6/2013 3:11 PM, John C Klensin wrote: On this specific point ... Less likely, but still possible, a candidate may disclose (presumably with permission based on the Nomcom's confidentiality obligations when needed) truly confidential material such as future job prospects or even plans within the organization for which he or she currently works. Again, if the candidate can't be assured that information will be kept confidential, with no pressure to disclose, we essentially discourage candidates who have information of that type that then cannot be revealed to the Nomcom. I've seen at least one Nomcom questionnaire that fell into this category, so I's suggest that John's point is worth keeping in mind. Spencer
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: quote Spencer summarized a private conversation with Mark Allman as, Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad /quote If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Spencer I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Re: Nomcom Reports
On 3/4/2013 2:31 PM, Mary Barnes wrote: As far as I can tell, the last official Nomcom report was from the Nomcom I chaired (2009-2010): http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? While this is not listed as a requirement in RFC 3777, I had understood as chair that this was a requirement for the job, but again, I've not seen that carried on. Personally, I don't find a few .ppt charts adequate in terms of summarizing the outcome of such an important IETF process. The Nomcom gains a unique insight into the operation of the IETF (and its leadership) that no one else gets. Mary, I found your report useful, especially when I served as the IAB liaison to the Nomcom the following year. I would like to see reports like yours in the future. Spencer I will note that of the 4 issues that I raised in the report, there are 2 that remain critical IMHO: - Section 7.1 Diversity. Out of the leaders across the IAOC, IAB and IESG, there is one individual from Asia and one female (both on the IAB). - Section 7.3. Expertise. Of course, this is directly related to the long thread of discussion underway with regards to filling the Transport AD position - i.e., it's the exact same situation faced by the 2009-2010 Nomcom. The other two issues are of course, important, but didn't appear to be such an issue for this year's Nomcom. Regards, Mary.
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Just as a follow-up here ... I was John's co-author on RFC 3933 (http://tools.ietf.org/html/rfc3933). When we were working on the draft, the problem I thought we were solving, was that the IESG needs to update the IETF's BCP processes from time to time, but (1) it was like 32 simultaneous root canals to actually get community consensus to modify the IETF's process BCPs including untried changes that might be improvements, so (2) the IESG was using informal IESG statements developed with much less community involvement than was expected for process BCP changes, in order to get anything done at all. I (and, I think, John as well) saw RFC 3933 process experiments as a middle path between lightweight IESG decisions and full process BCP revisions. That's what I thought Section 2 of RFC 3933 was trying to say. I had assumed that if the IESG clearly had discretion to do something under the current process BCPs, and thought it was the right thing to do, they would just do it, rather than set up a process experiment. For what that's worth. Spencer On 1/24/2013 12:34 PM, John C Klensin wrote: --On Tuesday, January 22, 2013 16:31 -0500 Thomas Narten nar...@us.ibm.com wrote: This document seems to have a bit of missing the forest for the trees. In the overall scheme of things, I don't believe the draft will materially help, and is at best a distraction from dealing with meaningful problems. The crux of the issue is that any attempt at fast tracking is fundamentally about short-circuiting some aspect of our review processes. We should only do that very carefully. In almost all cases, individual judgement is needed as to when it is appropriate to do that. ADs/WG chairs already have some flexibility here. e.g., a WG can skip WG LC if they think its ... Hi. First of all, I am completely in agreement with Thomas and his analysis. Anything that can reasonably and appropriately be done by this sort of effort can be done by discretion without adoption of a formal procedure and adoption of a formal procedure creates additional and unnecessary risks. As co-author of the process experiment model, I also object to its use when it is not demonstrably necessary, for example to give extra status and force IETF-wide use where the actions suggested can be carried out as a matter of normal discretion (see Section 5 of the document).
Re: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)
On 11/29/2012 3:16 PM, Adrian Farrel wrote: Just picking at one point... According to some RFC: All relevant documents to be discussed at a session should be published and available as Internet-Drafts at least two weeks before a session starts. If the above was followed there shouldn't be any draft submissions during the week a meeting is held. What about drafts that not for discussion at a session? What about drafts that have completed last call or are in IESG processing? Cheers, Adrian In addition to the cases Adrian asked about, isn't there also the case of an author/editor updating a draft that has already been discussed and then submitting it during IETF week? Thanks, Spencer
Re: Newcomers [Was: Evolutionizing the IETF]
On 11/10/2012 10:57 AM, Mary Barnes wrote: On Sat, Nov 10, 2012 at 10:51 AM, Melinda Shore melinda.sh...@gmail.comwrote: I think that we haven't done a sufficiently good job of acculturating newer participants and that can probably make the organization look more opaque and closed than it actually is. Most (but not all) working groups don't have enough help with document review, and I think that's probably the fast path to agency within the IETF. Being a body in a chair at a meeting is not. [MB] Exactly! That's what I did when I first started participating in IETF. I would review documents and comment on the mailing. I also would volunteer to take meeting minutes as that really does force you to pay attention to the meeting and not spend the meeting reading email or playing solitaire. Or, volunteer to at least follow the jabber room. Those are all extremely important for working group effectiveness. [/MB] What Melinda and Mary are suggesting is what's worked best for me. The only additions I'd make are: - It's worth noting that, this being the IETF, your ideas are going nowhere unless other people agree with and support those ideas (if working group participants won't work on your proposal, the working group won't adopt it!). If you contribute to other people's proposals, either by providing text or helpful review comments, it's easier to find people who will contribute to your proposals. - It's worth noting that *committing to* taking minutes is also useful, whether on a one-time basis, by e-mailing the chairs and volunteering a week before the face-to-face meeting, or on an ongoing basis as a working group secretary (most working groups still don't have one), is also appreciated (not least by working group chairs who can't start a meeting until they find a note-taker!). You still have to actually show up and take minutes, but if they know you're coming, you get extra points ... Best wishes, of course. The IETF needs more effective participants. Spencer
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
Thank you, Joel, for putting pen to paper (pixels to glass?) on this, and thank you, Jari, Randy, and Warren for sharing your thoughts. As was pointed out, we've had conversations about LIMs previously. It might be worth asking Ray to provide a paragraph or two on history and the motivations when some of the previous LIMs were discussed. My memory of the proposed 2009 Malta LIM (supplemented by Teh Google) was that the working groups planning to meet weren't just from one area of interest (something like four RAI groups, plus SOFTWIRES and BEHAVE). I don't know if that helps or hurts - at a minimum, RIPE/foonog may not be the draw for RAI that it was for the groups that met this time. FWIW, http://trac.tools.ietf.org/2009/jan-large-interim/ says 60 potential attendees didn't qualify as a large interim :-) Spencer
Re: IAB Seeks Executive Director
Hi, Thomas, Thanks for your help in the talent search! I haven't seen a reply to your note, but it's worth mentioning that the IAB ExecDir is no longer responsible for weekly telechat minutes, and at least some of the IT/web responsibilities performed by previous ExecDirs are moving to the secretariat. Input from previous ExecDirs would be more helpful if they subtract that out. Spencer On 12/15/2011 8:36 AM, Thomas Narten wrote: Given these tasks an Executive Director should ideally: + Have sufficient time available and be able to allocate that time to IAB tasks when needed. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. The Executive Director is expected to attend all IETF meetings and IAB Retreats and Workshops (typically two per year). The IAB has approximately 8-10 hours of teleconferences per month which require preparation and follow-up. Can we get some comments from previous Exec Directors (or others) about what the *actual* time commitment has been in practice? In encouraging folk to submit their names, I've been asked what the actual work load is in practice. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
Hi, Yaakov, I'm not the right guy to answer this, but I believe the right guy would say that when we are asked for evidence about prior art, it would be more helpful if you could actually read the presentations from the working group meeting where somebody's invention was discussed by other people three years before the data of the invention. I'm not defending that POV, only repeating what I believe the answer to be. Spencer On 11/17/2011 8:06 AM, Yaakov Stein wrote: Martin Where does the note well say that any contribution needs to be readable 10 years hence ? It says that if you submit/say something that it is under the IPR stipulations, and it says that the participant is deemed to have accepted rules of practice including that what is said/submitted may be made public. It does not say that everything that I say in a session must be transcribed and saved in ASCII, and what I present in slides is no different from what I say. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Clarification on EDU tram
Hi, Russ, I won't take plenary time to ask this, but ... My memory from being on the EDU Team for a while was that the EDU Team itself was broader than just the list of people who did tutorials - looking at what additional training was required, etc. Is that still true? It might be helpful for people to know as they consider their willingness to serve the community in this way. Thanks, Spencer, who hopes to help with EDU when he's not in IAB meetings on Sunday afternoons ;-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Clarification on EDU tram
On 11/16/2011 3:36 AM, Margaret Wasserman wrote: HI Spencer, We are responsible for the tutorials, which includes deciding what new tutorials are needed, and working with people in the community to deliver them. Not all of the people who _teach_ the tutorials are on the EDU Team, although there is some overlap. There as been discussion of the EDU Team doing some other things -- web training, for instance. With new membership/leadership, perhaps the EDU Team will be able to take on some of those tasks, as well. Margaret Thanks! Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
For what it's worth, I've been a repeat-offender note-taker for a bunch of groups at the IETF, and was doing that when we mass-created all the jabber.ietf.org rooms. It was obvious to me at that time (but I was wrong) that I should be continuing to take notes in the jabber room, so people had the chance to correct things I wasn't getting right, but the volume of my notes swamped the ability of anyone else to use the jabber room for discussion, asking questions, raising hands ... This was true for working group meetings, virtual interim meetings, the IESG telechats, and plenaries (so, across the board). There were several IETFs where there were two jabber rooms (one for sessions I was note-taking for, and one for other uses) for RAI working groups I was note-taking for, but that happened two or three years ago, and I haven't seen any meetings with two jabber rooms lately. Spencer - Original Message - From: Peter Saint-Andre stpe...@stpeter.im To: ke...@kismith.co.uk Cc: ietf@ietf.org Sent: Monday, October 24, 2011 10:57 AM Subject: Re: Requirement to go to meetings On 10/24/11 6:44 AM, Kevin Smith wrote: On Mon, Oct 24, 2011 at 1:37 PM, Dave CROCKER d...@dcrocker.net wrote: On 10/24/2011 4:09 AM, Peter Saint-Andre wrote: It's really not that big a deal. Make sure that audio is working, that there's a Jabber scribe/Jabber room watcher ... I have a concrete suggestion for WG chairs: don't ask for a Jabber scribe (which makes it sound as if the hapless volunteer needs to type everything that's said into the chatroom) but instead ask for someone to relay comments from the chatroom to the mic. Basic question: what has been the claimed purpose for doing jabber scribing? I thought it was a means of produce raw minutes. A side -- and sometimes extremely valuable -- benefit is as a relatively real-time alternative source of information about what is being spoken; this can be quite helpful for participants who are not native English speakers. If neither of these purposes are worth the effort, then your suggestion sounds dandy. If either is sufficiently valuable, then my question is why your groups haven't needed them. (I'm expecting the answer to be that your groups didn't feel the need; so my real question is why not?) FWIW, I've found Jabber scribes supplementing the audio stream useful because the audio stream alone isn't always sufficient to hear what's going on, or to know who's speaking. Problem is, it's a lot of work to scribe the audio, and it's not easy to find volunteers for that task. I do think it's helpful for someone to at least relay the names of those who step up to the mic, but that could be done with those little RFID badges we experimented with a few times. Peter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
We've come a long way. That would make sense to me. Spencer It was obvious to me at that time (but I was wrong) that I should be continuing to take notes in the jabber room, so people had the chance to correct things I wasn't getting right, but the volume of my notes swamped the ability of anyone else to use the jabber room for discussion, asking questions, raising hands ... IMHO, something like Etherpad is better than a chatroom for collaborative note-taking. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
For Mike, Marshall, and for others who might be noodling on this ... I hesitate to suggest this, but its probably time: Let's add a position to the IESG - Executive Vice-Chair or Co-Adjutor Chair. Basically, either the chair's personal representative (Executive Vice-Chair) or their replacement in waiting (Co-Adjutor Chair). In addition to about a billion other responsibilities, Russ is actually on the hook for the responsibilities we're discussing because he was selected by NomCom to be the - IETF Chair, - IESG Chair, and - General Area Director Mike is suggesting a change for the IESG Chair responsibility. Marshall (earlier in this thread) suggested a change for the General Area Director responsibility. I'm not offering an opinion about these proposals (or other proposals that someone might suggest), but it might be helpful to consider all three responsibilities as a set, when considering these proposals. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
Jari, I found your review comments to be very thoughtful and helpful. I understand the concerns you are raising, and I agree that your proposed way forward is reasonable. I did have one question: So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work: - what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444) - what kinds of application practices may be affected - what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc) Who was the we you were thinking of, making this statement? (I think I'm asking, would this statement be part of this draft, or something else?) Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
For what it's worth, I largely agree with John's statement of the justification for Olaf's proposal. Anything that the IETF can do, to make the IAB and IETF Chair positions less of a full-time (or more) job, is a good thing. I could be in the rough on whether this specific proposal is the right thing to do, but I'd feel better about rejecting it if the people who insisted that the IAOC and IETF Trust responsibilities could not be delegated, could make a counteroffer on how the overall workload for these positions could be reduced in a way that IS acceptable. It would be helpful if we could organize to reduce the time commitment for these roles. If not these responsibilities, what? Tugging at the various corners of a full-size fitted sheet on a queen-sized bed doesn't actually result in completely covering the mattress - it only wears out the sheet! Spencer p.s. in the interests of full disclosure, I am mentioned in the acknowledgements section of the draft John mentioned in his post, along with Joel Halpern, but I had completely forgotten about that until I saw my name :-) Have been alot of discussion and suggestion and problems but nothing that made me understand why, what is the underlaying cause. (it could be that I'm just slow, we shouldn't rule that out :-) ) Roger, The problem is that, over time, the IAB and IETF Chair positions have become full time (or more) jobs. Not only does that require a huge time commitment, but the roles require a broader range of skills and interests than are typically present in members of the IETF community. That situation, in turn, has several nasty effects. As three examples: -- If there are conflicting priorities and demands on time, something is going to get less attention than it deserves. The right people to decide what is most important in a particular case are the IAB and IESG, not a six-year-old document that doesn't allow for individual cases. -- Unless we have started believing in kings --even kings who, once elected, serve more or less as long as they are willing before stepping down-- the IETF Chair should not be lots more important, nor should we assume he or she is inherently more skilled in any given matter, than a consensus conclusion of the IESG. The IAB Chair should be even less so. These people are given roles of leadership and responsibility, not someone anointed with infinite wisdom and time -- or even absolute knowledge of what is good for the IETF and the Internet -- at the time they assume those positions. -- The pool of plausible candidates for the positions is significantly reduced because, especially in difficult economic times, there aren't very many people who can find sufficient support for a long-term (nominally two years but four or more in practice) full time commitment plus a large expense account for a lot of travel, etc. Unless we want to be in a situation in which candidates for those positions are selected almost entirely on the basis of who has the resources, we had better be looking for ways to reduce the scope of the positions. While I think Olaf's current proposal is better in several ways --including the provision that enables the Chairs to participate as ex-officio members when they think it is appropriate, if you are interested in a more lengthy discussion of basic cause, there is a more extended discussion of the issues (and largely the same core proposal) in the now-rather-old http://tools.ietf.org/id/draft-klensin-iaoc-member-00.txt john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
Murry, I think I agree that a wiki page for every RFC is too chaotic an idea to be workable. I agree with the thought that the suggestion under consideration could usefully be amended as a wiki page for every RFC that needs one. If I write a specification, it's published as an RFC, and we don't need to say much else, we don't need a wiki page for that. I'd like to suggest an amendment as a wiki page for every protocol that needs one. One of our problems is that we haven't come up with a useful way of grouping specifications that, taken together, describe a protocol, at some specific point in time. STDs should have been that grouping, but the failure for so many standards-track specifications to advance to full Standard made STDs much less relevant in the IETF as we have it today. When we've done summary documents for protocols that have been massively extended over one or more decades (I'm most familiar with TCP - RFC 4614 - and SIP - RFC 5411), I think those have been very useful, but they tend to be published once - they aren't living descriptions of the protocol as it evolves. Perhaps we should be thinking about how we maintain our body of corporate knowledge at the protocol level, which is not necessarily the individual RFC level. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Hi, Dave, Anything that the IETF can do, to make the IAB and IETF Chair positions less of a full-time (or more) job, is a good thing. Anything? I believe you do not believe that statement, but I think it accurately summarizes the focus of this thread, so far. Thanks for the wake-up call, of course. Now, it's Monday AFTERNOON in my time zone. I am carefully reading the notes that were posted after I posted. I noticed that John Klensin says not JUST an offload proposal - and I get that - and I hadn't fully grokked the fiduciary responsibility point Marshall made. So, yes, I overspoke. Like I said - I'm fine being in the rough on this proposal, but I would like us to think about if not this, what gets offloaded? Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
I'm speaking as an individual, albeit an individual who helped with the decrufting effort in NEWTRK ... http://www.ietf.org/rfc/rfc4450.txt, for those who missed it. undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. Given that these are pre-IETF RFCs, I move that we create a new designation of Pre-Historic. I think Peter's suggestion is brilliant, but it point out a disagreement about what Historic means, in the IETF. Quoting Keith Moore, from later in this thread: Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used. Keith is mirroring the criteria used in the RFC 4450 decrufting effort, which was not reflecting documented practice in the world today, which the IETF community isn't well-placed to know. So moving things to Historic is Really Hard. A different but related problem is that moving a specification to Historic, for at least a significant part of the community, doesn't just mean it's old, it means and you shouldn't use it. The issue *I* thought we were dealing with in the decrufting effort wasn't specifications that had been superceded or otherwise obsolete (the RFC 2026 definition of Historic); the problem was specifications that no one still active in the IETF had worked on - or at least, no one would admit it! - and no one was willing and able to work on. I thought at the time that our criteria shouldn't be whether anyone was USING the specification, what mattered was whether anyone in the community had the interest and expertise to maintain or extend the specification. It's not as if the RFCs disappear in a puff of smoke when they are recategorized, ... I was in the rough on that one in 2005, but since we're looking at another bulk recategorization effort, I might make this suggestion again - perhaps we could define a new level, which might be called something like Not Maintained, with the criteria as, we can't identify anyone who is willing and able to maintain the specification That's actually something the IETF COULD know. We could ask, and if we hear crickets, Not Maintained. If somebody shows up later, recategorize. No presumption that you shouldn't use the specification, only that you shouldn't expect the IETF to maintain it. And if that's a problem for you, please feel free to start identifying people who are willing and able to maintain it. If Mykyta was planning to identify pre-IETF RFCs as Not Maintained, that might be less controversial. And I'll leave the suggestion to move the Historic parts of 2026 to Historic, to someone else :D Spencer, as an individual ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-eggert-successful-bar-bof-06
Lars, For what it's worth, I have the same question as Ben - if this guidance applies to the kinds of informal meetings in restaurants and bars that the IESG is encouraging, even if they aren't publicized and aren't open to the community, is there any way for two or more IETF participants to talk to each other, that's NOT under NOTE WELL? I think it DOES make sense to say that the kinds of informal meetings the IESG is discouraging - in IETF meeting rooms, with agendas, mailing lists, presentations, attendee lists, and minutes - should include NOTE WELL notifications. But if I was sitting next to Adam Roach on a plane headed for the IETF (which has happened before) when he was editor of GIN and I was chair of MARTINI (this last part did not), and we started talking about proposed changes to the GIN draft, is that covered? Color me confused ... Spencer -- Section 6 suggests side meetings should be (somehow informally) covered by NOTE WELL. I think this is a very dangerous suggestion. The rest of the document suggests that a side meeting has no official standing. That seems to me to mean it's no different than a group of people who coincidentally participate in the IETF having a dinner or bar meeting on any subject at any time. Or a hallway conversation, for that matter. By the logic of this section, I can't really figure out how informal a meeting would need to be before it no longer fell under NOTE WELL. In an informal meeting, the participants should be able to follow any IPR policy they like. I can even imagine an informal meeting covered by an NDA, where the participants want to decide if they want to have further discussions of a subject under IETSF IPR rules or not. I think the best we can hope to do is suggest that side meeting organizers and participants be explicit with their expectations on IPR and confidentiality, so there is less chance for down-stream surprises. If we want something stronger than that, then we really need to create a new category of official meeting. We actually ran this question past the IETF legal counsel before adding that section to the document. It was his stated opinion that the Note Well applies. I therefore don't see what we could do here. Did the counsel describe the triggers that causes Note Well to apply in general? Because if it automatically applies to an unofficial side meeting, then it's hard for me to see where it _doesn't_ apply when 2 or more IETF participants have a conversation. For example: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Minimum Implementation Requirements (Was: 2119bis)
Hi, Melinda, Can anybody point to an incident in which lack of clarity around 2119 language caused problems, and it was determined that 2119 itself was the problem and not authors or editors being careless? Melinda My recollection is that, at least since the early 2000s, most problems were encountered with Last Call/Gen-ART (and probably other review team) comments taking forms like Why is this SHOULD not a MUST?, or the ever-popular Why is this Informational draft using 2119 language?? There are probably variants I don't remember (I stopped being an active Gen-ART reviewer when I began serving on the IAB, and I've slept since then). In my comments on 2119bis (http://www.ietf.org/mail-archive/web/ietf/current/msg68885.html), I was suggesting that clarifications might head off some of these recurring conversations. At this point, I would be fine with a draft (of any flavor - obsoleting, updating, or just an IESG statement) that addresses whether these questions are reasonable questions. I don't have a deep need to add the (mostly reasonable) suggestions that have been made for new terms. If the IESG thinks that's a reasonable thing to do, they can make a call about the particular flavor, just fine ... Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Dear Jari, During the discussion of the two maturity levels change, a question was brought up about DISCUSSes appropriate for documents that advance on the standards track. We discussed this in the IESG and I drafted some suggested guidelines. Feedback on these suggestions would be welcome. The intent is to publish an IESG statement to complement the already existing general-purpose DISCUSS criteria IESG statement (http://www.ietf.org/iesg/statement/discuss-criteria.html). Here are the suggested guidelines for documents that advance to IS: http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt Comments appreciated. Please send comments either on this list or to the IESG (i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011). Jari As with 2119bis, thank you guys for putting this together. The text in http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt says IESG reviews should be considered as a review of last resort. Most documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail. I might have thought that the point for documents advancing on the standards track is that they already have *IETF* consensus (especially if they are being advanced without text changes), so the IESG cannot overrule *IETF* consensus without good reason ... which seems like a higher bar (one can more easily assume the existence of a rogue working group producing a rogue Internet-Draft, than a rogue IETF that is still sane enough to NomCom-select non-rogue ADs who will push back on rogue standards-track documents advancing :-) So perhaps s/informed working group consensus/informed IETF consensus/? I note that this isn't quite tying the IESG's hands (I'm reading this descriptive text as the moral equivalent of MUST NOT overrule IETF consensus without good reason, which leaves one hand free). Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Keith, Yes, to what you are saying, but I was pointing out that the text we're discussing isn't intended to apply to moving what a working group has consensus for onto the standards track, it's intended to apply to what the *IETF* already has consensus for, that's already on the standards track, further along the standards track. I think there's a higher bar, especially when a document is advancing unchanged, because I don't think there's any meaningful distinction between a widely deployed PS that could be improved, and advancing it to be a widely deployed IS that could be improved. I don't see the value-add from DISCUSSing the advancement, because the same document is sitting there as a proposed standard, and widely deployed. If ADs look at a document proposed for advancement and see real and meaningful opportunities to improve the specification, I think it makes just as much sense to advance the document, as is, and start looking for people who will produce an improved version, as to slow down the document for DISCUSSion in the hope you end up with an improved document, that can then advance. Finding those people, and chartering that work, falls well within the S in IESG, AFAICT. Thanks, Spencer - Original Message - From: Keith Moore To: Spencer Dawkins Cc: Jari Arkko ; IETF Discussion Sent: Wednesday, August 31, 2011 10:35 AM Subject: Re: Discuss criteria for documents that advance on the standards track thanks Spencer for pointing this part out. On Aug 31, 2011, at 11:23 AM, Spencer Dawkins wrote: IESG reviews should be considered as a review of last resort. Most documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail. The idea that WG consensus should prevail is simply incorrect. It biases IESG in an inappropriate way. There are a number of very good reasons for overriding WG consensus, e.g. - there is no evidence of broad community consensus or a clear lack of broad community consensus - the document does not meet the criteria specified in 2026 (or other document when applicable) - the document is ambiguous in such a way that it is likely to degrade interoperability The WG DOES NOT represent the entire community.Far too often, WGs are deliberately chartered in such a way as to marginalize parts of the community Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Umm, wait. I'm confused. The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, right? What am I missing? Spencer - Original Message - From: Keith Moore To: Marc Petit-Huguenin Cc: IETF discussion list ; Eric Burger Sent: Tuesday, August 30, 2011 11:11 AM Subject: Re: 2119bis I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Peter, Thank you for submitting this draft. It clarifies some of the most consistent sources of cyclic discussion that appear on the IETF discussion list. I have a couple of questions. The most consistent source of cyclic discussion that I didn't see addressed, is the use of RFC 2119 conformance terms in requirements drafts, and various other flavors of non-standards-track drafts. The draft itself explicitly targets standards-track documents. My impression is that acceptable practice varies across the IETF, so (at least when I was an active Gen-ART reviewer) this came up from time to time in cross-area reviews. Is there anything the IESG can say about this, to give guidance to the community? Sections 2.3 and 2.4 leave the requirement to say why one might not implement a SHOULD (and SHOULD NOT) as, well, a SHOULD. To ask the meta-review question, is there a reason why explaining a SHOULD (and SHOULD NOT) is a SHOULD, and not a MUST? :D It's fine with me if the list of reasons isn't complete (so, SHOULD = do X unless you have a good reason; good reasons include Y, and there may be other good reasons would be implicit), but a bare SHOULD (or SHOULD NOT) with no explanation doesn't seem helpful. I've been told by some working groups we think doing it is a MUST, but some deployed implementations don't do it, so it's a SHOULD. If that's the reason, perhaps writing it down would be healthy. And I'd really like to see discussions of consequences as a MUST, even if explaining a SHOULD (or SHOULD NOT) remains a SHOULD. I hesitate to bring the last one up, but I also see drafts that use the formulation MUST do X unless Y. Would it be helpful to mention this? I believe MUST X unless Y is the moral equivalent of a SHOULD - perhaps you don't have to do anything except say that? Thanks again for doing the work. Any cyclic discussion we can stop cycling on, is a beautiful thing! Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-eggert-successful-bar-bof-05.txt (Considerationsfor Having a Successful Bar BOF Side Meeting) to Informational RFC
I have been looking at various revisions of this draft since -00. I'm glad Lars did the first version during IETF 77, and I'm glad that Lars and Gonzalo kept working on it. I think it's important guidance for the community. I think it's on the right track. I think it could reasonably be published in its current form. I have some suggestions. Frivolous: I TOTALLY get the don't call it a Bar BOF thing. I've also seen the confusion that results from any sentence that includes the words Bar BOF, and it might even be worth pointing out that even IESG members and IAB members drop the Bar in conversations from time to time, especially during IETF week, resulting in even more confusion. Side Meeting could work, but it covers a lot more than the kind of pre-charter planning meetings you guys are talking about for most of the document, and you have access to a community of thousands of creative people - could you think of a better name? If the search space you're dealing with requires references to alcohol, just ask Hadriel Kaplan for a suggestion. He came up with MARTINI ... :D More seriously: We're now more than two years into the implementation of the RAI DISPATCH process, and RAI DISPATCH has a lot to do with bringing new proposals into RAI. It seems odd that there's no guidance specific to RAI DISPATCH, especially because the current revision also talks about working group ad hoc meetings, which RAI DISPATCH often uses. It might be helpful to mention something about the RAI DISPATCH process - either in this document, or in another that deals specifically with working group ad hoc meetings. And, actually, the discussion of working group ad hoc meetings seems to have parachuted into the last paragraph of Section 2, with little in the title or abstract that would lead anyone to suspect that it might be hiding there ... so maybe moving it to its own, very small, document would be helpful. Minor suggestions: In Section 2, there's a discussion of tourists. It might be helpful to distinguish between the times when you WANT tourists - when you're asking the entire IETF community for input - and the times when you DON'T - when you're trying to wordsmith a charter, etc. The text describes the second case nicely; I'm just suggesting that you you include a sentence on the first case, and say you need to hear from the entire community at the right time, but your side meeting probably isn't the right time. Also in Section 2, where you give the don't count bodies warning, you might also add that people come to meetings about proposals for new work just to make sure that the proposal isn't going off-track in ways they care about - and if it's not, that's fine, they aren't interested in DOING the work, so they disappear. So the area directors know not to count them as interested, too. Somewhere in Section 2, it would be worth noting that collecting large groups of people in side meetings tends to result in larger proposed working group charters, which makes it harder to get chartered. The IESG has not had a problem with charters that were too limited in scope coming out of side meetings, at least not since I joined the IAB ... Section 3 contains this text: Many routinely say yes to every incoming request as long as there are meeting rooms available (and there are typically lots of meeting rooms available). I'm betting that the parenthetical should be available, outside of normal working group meeting slots. Section 3 contains a sad tail of woe about an area director being trapped in a hotel for a few days during IETF 77, but I'm thinking area directors are going to be trapped in hotels for a few days during IETF weeks, whether there are side meetings scheduled during meals or not. There might be a few points conflated here - (1) my understanding is that most area directors are trying to dodge side meetings, because the very presence of an area director signals gee, Gonzalo came, he must be interested, and if he's interested, he'll approve us as a working group soon! - if the area directors ARE dodging side meetings, you might say that, so everyone has realistic expectations; (2) if you schedule a side meeting during a meal break, everyone there will be missing a meal unless you go to a restaurant like we told you, and (3) if you schedule a side meeting that looks like a BOF during a meal break, you won't fit into most restaurants, so have a small side meeting and go to a restaurant like we told you :-) In Section 4, when you're describing the problems of holding side meetings that are indistinguishable from IETF working group meetings, you might include the point that we've seen situations where people think the work has already been chartered, even making press announcements about that. No one makes the same mistake when you meet in a restaurant! Also in Section 4, where you say Finally, some organizers may find the process to apply
Re: A modest proposal for Friday meeting schedule
Peter, A side benefit is that the IESG/IAB could have a lunch meeting on Friday (as opposed to the current breakfast meeting) and cover all the hot topics from the week (not the week minus Friday). /psa I agree with your point here, and add that the joint IAB/IESG Friday session isn't only a BOF report session, it's hot spots, however defined - we've usually at least SEEN all the BOFs by Friday breakfast, but that doesn't mean we've seen all the hot spots ;-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their responsibilities to other persons. The delegations by the IETF chair and the IAB chair need to be confirmed by the IESG and IAB respectively. The terms of delegation is for a longer term for instance aligned with the IESG and IAB appointment cycles (roughly anual). It reads as a generic may delegate their responsibilities. So taking that paragraph out of context may confuse people. Why not make it explicit: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their IAOC and/or IETF Trust responsibilities to other persons. ... ACK We do have some wordsmithing to do, and we're doing it (I agree with Bert's suggestion, will senda note about Barry's question), but I support the high-order bit of this draft, and would be OK with either Olaf's model or John's model in the previous draft. I can say more about why, but I'll wait to see whether that's necessary. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
I was not assuming that delegation was limited to another member of the same NomCom-reviewed body. One case was that you might delegate to a NomCom-reviewed member who then leaves the NomCom-reviewed body. If the NomCom-reviewed chair and the NomCom-reviewed body were OK with that person continuing to serve as the delegate, how wrong is that? I was assuming that the delegating chair/CEO would still be responsible for the performance of this role, and the IETF Chair and IAB Chair are both evaluated by NomCom, so I'm not sure why this is different from being a liaison manager to another SDO - the IAB is responsible for shepherding that liaison relationship, but most of the liaison managers are not NomCom-reviewed (and none of them are NomCom-evaluated as liaison managers). I would be OK with adding serves at the pleasure of. I understood Olaf's text to cover for more than one IAOC telechat, but not for life, and would be OK with saying and while this delegation is effective. But I'm still thinking, of course. Spencer - Original Message - From: Barry Leiba barryle...@computer.org To: Henk Uijterwaal henk.uijterw...@gmail.com Cc: ietf@ietf.org Sent: Wednesday, March 30, 2011 7:29 AM Subject: Re: IAOC: delegating ex-officio responsibility I agree with Henk's modification -- in fact, my brain read it into it already, which is why I didn't say it too. The delegation should only be allowed to another member of the delegator's body. I think you mean: The delegation is for an one year term, aligned with the IAB and IESG appointment cycles and can be renewed. Ah. Why, then? Shouldn't the delegation be at the pleasure of the delegator, without an explicit term? If the officer sees the need to reclaim the ex-officio position directly, she should be allowed to. If the officer thinks the delegate isn't doing well, she should be able to change the delegate. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] xml2rfc and legal services RFPs
Hi, J.D., But I do think posting draft text does allow you to say and the community saw this if you guys get any pushback at all... +1 The same process internet-drafts go through, right? Or as close as makes sense. If process means a chance for the community to look and comment before it's too late, yes, exactly. That's what we do for Internet Drafts, and it's almost certainly easier to make a contract that's in effect go away, than to make an RFC go away :D My sense is that the community is trained to back off (not completely, but at least significantly) when told yeah, and the working group considered that, yeah, and the NomCom considered that, or even yeah, that came up in IETF Last Call, and the IAOC might benefit if they could make the same point about RFPs. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] xml2rfc and legal services RFPs
For what it's worth, I agree that when you're talking to the community about RFPs, it's great if that doesn't turn into a wordsmithing exercise on the ietf mailing list, And I agree that providing a list of things that lawyers have already done for us is a very reasonable basis for an RFP about what we expect lawyers to do for us, But I do think posting draft text does allow you to say and the community saw this if you guys get any pushback at all... Thanks, Spencer Bob, On 2011-02-22 08:23, Bob Hinden wrote: John, Support for the xml2rfc tool was discussed on the IETF mail list when Marshall Rose indicated he could no longer support the tool. Several people volunteered to maintain the tool, and they recommended the it be rewritten. That recommendation plus the realization that this tool had become critical to IETF operations resulted in the IAOC deciding to issue a public RFP for a rewrite. The Statement of Work in the xml2rfc RFP was reviewed and modified by the people on the tool-development list. You can read the discussion at: http://www.ietf.org/mail-archive/web/tools-development/current/maillist.html There was an active discussion that resulted in many changes from what was first proposed. While this wasn't the whole community I think it a good representation of the people who are interested in the xml2rfc tool. I will send you the list members off line. Also, we will use a subset of this group to review the bids. I think the tools development list was a good venue for the detailed discussion. Was the process mentioned on tools-discuss too? (I dropped off that one a while back, due to lack of cycles, but it does seems the obvious place, not to mention the xml2rfc list, where I don't recall it being mentioned). The legal services RFP was developed inside the IAOC/Trust. To be honest, I didn't see very much value in doing a community review for this. We will consider it in the future. I do note that this work was previously done without a public RFP (dating back to when Wilmer-Hale was providing the service) so I think this is a better process than what was used earlier. In the future, we will strive to give more notice to the community on planned RFPs. I think that is appropriate, given the comments in BCP 101 about transparency. But I agree that for legal services, our community doesn't particularly have the skills to wordsmith an RFP. Brian Bob p.s. I will forward your specific comments to tools-discuss. On Feb 19, 2011, at 8:49 AM, John C Klensin wrote: Hi. This is not an attempt to derail either of these RFPs, nor is it a formal appeal (request for review). However, these two RFPs raise an issue that may be worth some consideration. The clear intent of the discussions leading up to RFC 4071/ BCP 101, and some of text in that document, was that the IASA was to act with maximum transparency to the community and openness to community comment. It is especially important that substantive decisions be open for community review and discussion before they are made because, especially for those that are eventually represented by contracts, there is no mechanism for review later. IASA has recently issued two RFPs -- for legal services and for a reprogrammed version of xml2rfc -- with no advance indication to the community (at least that I can find) that they were coming or opportunity for the community to review draft provisions. The clear expectation is that proposals will be submitted (on a fairly short timeframe) and that the IAD and IAOC will do whatever they do to evaluate the proposals and establish contracts. I don't know whether that is harmful in these particular cases, but I don't believe it is how the community had intended that things be done. FWIW, community discussion might have improved at least the XML2RFC one -- either the details of the RFP or community confidence that it addresses/includes the right specifications. For example, of the very large number of extensions or additions that have bee requested over the years, the RFP selects two (explicit line breaks in titles) and alternate anchors for citations/references) but ignores the others. I know that the ability to easily index and cross-reference items in bulleted lists, to easily generate numbers for ABNF productions (rules) and build an index of productions, to have indexing reflect section (and other subdivision) numbers rather than page numbers (as various RFC style guides have required for years and that becomes particularly important as people contemplate non-paginated output formats), the ability to properly reference books and journal articles without resorting to odd tricks involving seriesInfo, and better handling of widows and orphans (especially with regard to section title-text and lists with undented headings top my personal list, but there are certainly others. In addition, one of the two extensions that was specified involves the addition of a new
Re: Use of unassigned in IANA registries
Phillip, Lars can speak for himself, but what I THOUGHT he was talking was changing the phrase unassigned to something like reserved for future assignment. That made sense to me... Spencer - Original Message - From: Phillip Hallam-Baker To: Lars Eggert Cc: Iljitsch van Beijnum ; paul.hoff...@vpnc.org ; ietf@ietf.org Sent: Tuesday, January 18, 2011 7:51 AM Subject: Re: Use of unassigned in IANA registries On Tue, Jan 18, 2011 at 2:46 AM, Lars Eggert lars.egg...@nokia.com wrote: Hi, On 2011-1-17, at 1:23, Phillip Hallam-Baker wrote: If people think that IANA is a tool they can use to impose their own personal political agenda on the Internet, they are mistaken. that isn't the point of this thread. The point of IANA assignment is to avoid conflicting codepoint usage. Squatting on codepoints defeats this goal. But it meets the goal of the people squatting. Is there any reason to think that changing the name of the code points is going to make a difference? I know of about 5 or so TCP option numbers that are being squatted on at the moment (there are likely more). I've been in discussion with the folks who are squatting, and in all cases the story was either we were going to ask for assignment but it got forgotten or oh, you mean unassigned doesn't mean it's free for the taking? Those sound like excuses to me rather than reasons. I am currently applying for a DNS RR code assignment. More than one person involved suggested that we should just assign the RR code ourselves by fiat because they didn't want to wait six weeks for a review. My name is on the draft so we have applied for an assignment. But now that six weeks have passed we have a major industry meeting next week that is to discuss the proposal (amongst others) as part of a DNSSEC deployment effort and there has been no response. Using a term other than unassigned might prevent some instances of the latter. I don't see how changing the name is going to affect behavior for the positive here. If you do succeed in confusing people as to which numbers are unassigned and which are not it is going to increase the risk of a collision. If five people are experimenting with TCP options and this is not causing collisions, what is the problem? -- Website: http://hallambaker.com/ -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
I like the idea of using break time for these conversations, much better than either burning a regular meeting slot or expecting poster authors to hang around all day waiting for interested parties to surface ... if this goes forward, that's what I would suggest. Thanks, Spencer On Jan 10, 2011, at 8:57 AM, Yoav Nir wrote: On Jan 10, 2011, at 1:09 PM, Henk Uijterwaal wrote: The costs for a poster session are almost 0. Isn't this something we can just try? I don't agree that the costs are zero. You can't have the poster session last all week long, because the presenter may want to go to other sessions. So we need about 2 hours reserved for this. Maybe a morning session. What I would suggest (if this goes forward) is - some space is set aside, ideally in or near the break area / room - posters SHOULD be put up in the AM, starting at breakfast. - the last refreshment break of the day, the authors are supposed to be at their posters. (They can be at other times, but they SHOULD be at this time.) People could then read posters at any time during the day, come back at the break and ask questions, raise issues, etc. ADs could also quickly judge the interest in a poster, by how many people are haranguing the author. As the session would last one full day, different days could accommodate different areas. Regards Marshall But then scheduling a WG meeting at the same time is like scheduling a TV series episode opposite the superbowl (substitute your country's favorite sport finals here). And all the ADs would want to go to the poster session, because that's where the action is. So this reduces the amount of time slots that we have in an IETF week. Also, this puts another constraint on choosing a venue. You need an area with room for lots of people, and space to put the booths or desks all around. For example, Anaheim did not have a good area to hold a poster session. Maastricht did. No idea about Beijing. It may be a cost we agree to bear, but it is not zero. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Two step, three step, one step, and alternatives
Eliot, I'm agreeing with John here, but have one addition ... Call it what you will, this sounds like NEWTRK revisited. What will be different? At least three things... maybe. First, I/we have been told repeatedly that this is a new IESG and that, even were we to revisit NEWTRK exactly, we might well see a different result. First.5, I might add that NEWTRK was in the perfect storm of ADMINREST, a flock of other GEN-area working groups and BOFs (ICAR? MPOWER? what were the others?) and pretty much zero transparency. I note that the last NEWTRK meeting, in Paris, was almost exactly the time that the IESG added scribes to provide narrative minutes - from the official secretariat-provided minutes, it's pretty much impossible to tell if any of the NEWTRK topics were ever discussed, and if they were, who on the IESG expressed concerns, and what those concerns might have been. None of those conditions are still true today. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternative Proposal for Two-Stage IETF Standardization
Russ, Dave: This is a significant improvement from my perspective. We need a mechanism to implement it. The mechanism does not need to be heavy weight, and it might be as simple as some statements in a Last Call, allowing the community to support or challenge them. Russ Thank you for the hallway conversation on this. When I counted last week, only 80 implementation reports have been filed with the IESG in the history of ever, so this doesn't seem like the right hurdle for advancement. I think your suggestion to make assertions at Last Call time and asking for supporting/challenging statements sounds very reasonable. The IESG can do the right thing based on Last Call comments. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternative Proposal for Two-Stage IETF Standardization
I think it would be sufficient to say something like: The following implementations represent a significant Internet deployment and they are based on the specification in RFCn: -a -b -c - ... wfm. and seems very reasonable to me as well... Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternative Proposal for Two-Stage IETF Standardization
Hi, Ned, Russ, Dave: This is a significant improvement from my perspective. We need a mechanism to implement it. The mechanism does not need to be heavy weight, and it might be as simple as some statements in a Last Call, allowing the community to support or challenge them. Russ Thank you for the hallway conversation on this. When I counted last week, only 80 implementation reports have been filed with the IESG in the history of ever, so this doesn't seem like the right hurdle for advancement. I assume that figure was arrived at by looking at: http://www.ietf.org/iesg/implementation-report.html If so, it's apropos of nothing, since the list is incomplete. Just as one example, MIME interop info isn't on it, and that information definitely was generated. Yes, that's correct. That's where the figure came from. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
Assuming, of course, that we continue to expect that the IESG will do the right thing, whatever that turns out to be ... Henk == Henk Uijterwaal h...@ripe.net writes: Henk So, I'd take it a step further: Starting Monday morning, 2 of the 7 Henk or 8 meeting slots in each session are reserved for BOFs and the other Henk 4 or 5 for WG meetings. That way, we'll have all the BOFs done by Henk Tuesday lunchtime, giving time to discuss the results during the week, Henk and impact on the rest of the schedule is minimal. I think this is the best idea. I agree with this - front-load the BOFs, but not to the point where they collide with related BOFs (do the right thing, whatever that turns out to be ...) If the rooms for the BOFs are clearly identified, then we can also easily give the BOFs 1hr slots rather than the 2.5 hour slots that occurs most mornings. My understanding of what BOFs are supposed to do, is that WG-forming BOFs should be demonstrating that there is a group of people who will do the work described in a proposed charter, and that they roughly agree that the proposed charter describes what they want to do. If that's so, we should rarely have a WG-forming BOF that runs over an hour - and if THAT'S so, it will be easier to schedule BOFs early in the week without colliding with other BOFs. The bunch of people get together and talk kind of BOF don't need to be so constrained on time - I'm focused on WG-forming BOFs when I say this. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (wasRe:
Hi, Yoav, Recognizing that we all work in different parts of the IETF, so our experiences reflect that ... RFCs have one big advantage over all kinds of blessed internet drafts. The process of publishing an RFC gets the IANA allocations. Every implementation you make based on a draft will ultimately not work with the finished RFC because you have to use some private ranges of numbers. I have a feeling (not backed by any evidence) that part of the reason people rush to publish documents is the need to get IANA assignments for their implementations. I know that getting IANA allocations is a major consideration for one of the SDOs I'm liaison shepherd for, so my experience matches this (of course, there are various IANA policies - if a registry is first-come first-served, this isn't a consideration). If we could have some kind of viable, promising or 1st review status for an Internet Draft, where the IANA assignments can be done on a temporary basis, I think this could allow for better review later on. I have no idea, though, how to get rid of the need to support legacy implementations argument that will arise later on, if changes to the protocol are proposed as part of the review. Again, this depends on the instructions to IANA - some policies are easier to accommodate than others. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (wasRe:
You could call me a blue-eyed optimist, but I have brown eyes ... What other motivation could there be to publishing documents earlier than vendors implementing and shipping it earlier? And if they do that, there is hardly any room for any substantial or backwards- incompatible changes. And the size of the installed base created by the early adopters significantly limits usefulness of any features or backwards-compatible changes that are incorporated into later revisions of the document. I think you're conflating two steps here: - implement and test, including interop testing - shipping in a product There is a reason to implement and test, including Interop testing. Robert Sparks can speak (orders of magnitude :-) more authoritatively than I can, but my impression from looking at SIPit reports, is that people in the RAI community really do have implentations, including implementations used for interop testing, that are NOT present in their products, and they do expect to feed back based on interop testing and see changes to the protocol that might require implementation changes. But beyond this ... you can implement any draft - you just have to think that's a good idea, and right now, people are making the decision to implement any particular draft with no guidance. In a previous life, I worked for a company making network monitor equipment. We hade requests from large carriers to support monitoring one of the SIGTRAN specs - I'm thinking it was https://datatracker.ietf.org/doc/draft-ietf-sigtran-sua/ - in about six different flavors of the draft (out of the 16 versions published as working group documents). - All had been implemented. - All had been deployed. - No two were 100-percent compatible. - None carried an identifier that said this is -09 or whatever, so we used heuristics to guess which version of the protocol we were looking at. - Some carriers had more than one version of the protocol running in the networks (-07 between these two boxes, -09 between these other two boxes). And none of these large carriers had waited for a proposed standard (it still hadn't been approved for publication when they were asking us to support six flavors of the draft). If having a working group say we think this version of the draft is stable enough to code to is going to make things worse, I wouldn't mind understanding why that's true. I will agree that I hear people say we can't change the spec from v03 of this because people have implemented it, but looking back, they were pointing to TINY communities, compared to real deployments that happened later. In the case I was talking about with Eric Berger yesterday, the can't change the spec from -03 because people have implemented it draft was finally published at -08. -03 DID change, several times. If someone manages to make a convincing argument to protect an early deployment to a tiny user community, that prevents us from solving problems with a protocol that would allow wider deployment, that's our fault. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2010-2011: READ THIS: Important Information on OpenDisclosure
Ummm, no. So would you even make public the comments that people send in? IMHO we have not agree to this (and I wouldn't support it). Ross Here's the new text from RFC 5680 (and it's all additions, no deletions or changes) at the end of the three paragraphs in [RFC3777], Section 3, General, bullet 6, which are currently: All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The nominating committee and confirming body members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members and all other participants are expected to handle this information in a manner consistent with its sensitivity. It is consistent with this rule for current nominating committee members who have served on prior nominating committees to advise the current committee on deliberations and results of the prior committee, as necessary and appropriate. add the following paragraphs: The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The list of nominees disclosed for a specific position should contain only the names of nominees who are willing to be considered for the position under review. The NomCom may choose not to include some names in the disclosed list, at their discretion. The NomCom may disclose an updated list, at their discretion. For example, the NomCom might disclose an updated list if the NomCom identifies errors/omissions in a previously disclosed version of the disclosed list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to be considered before the NomCom has completed its deliberations. Nominees may choose to ask people to provide feedback to the NomCom, but should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior. IETF community members are encouraged to provide feedback on nominees to the NomCom, but should not post statements of support/ non-support for nominees in any public forum. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [78attendees] WARNING !!! Re: Maastricht to Brussels-Nat-Aero, Sat 07:09
If this was some place in the US, I could easily find a cheap hotel chain nearby (like I did in Anaheim). In Europe, it's a little more difficult, but still doable (thanks, Google Earth). In China, I have no idea where to even look. Sure, I can find a list of cheap hotels in Beijing, but I have no idea where they are in relation to the meeting venue, or whether the staff would speak English. The warning to have your destination written down in Chinese, because the taxi drivers don't speak English doesn't inspire confidence either. For most business meetings, all this doesn't matter. You either have a host that helps you out, or your Chinese sales office helps you out. For an IETF meeting, we don't really have either of these. Just as a data point, I was in Beijing for the PPSP workshop at the beginning of the summer, and was able to come up with google maps to/from my hotel, which was not the conference hotel, with enough Chinese that I could hand the maps to a cab driver. I'm not a native, but my impression is that one of the things you're paying for at high-end hotels in China is staff that speaks English - but I've never stayed at a hotel in China where no one spoke English; it might be that just one or two people who spoke English, and everyone else would go fetch someone when I needed to answer a question. The only real point of confusion for me was that I didn't know what terminal I was DEPARTING from, when exiting China. Both Star Alliance and OneWorld fly out of the massive Terminal 3 (read more about this at http://en.wikipedia.org/wiki/Beijing_airport), but I didn't know that, and it took a little while at the hotel to figure out what to tell the cab driver. I put the address given at the IETF website (29 Zizhuyuan Road Beijing 100089 China) into Google Maps, and then zoomed out - looks like we're in Haidian District (http://en.wikipedia.org/wiki/Haidian_District, the university district). If you include the district in your searches for hotels, that will at least keep you from being at the other end of Beijing... Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Varying meeting venue -- why?
(snork!) Why do we not simply choose a single venue and have all our meetings there? Or perhaps three venues, one on each continent of interest. Figuring out where to meet is Hard. I'm glad the NomCom can find people who will play this game for no salary. Just to mention one point for amusement ... We've met in Yokohama, and we've met in Adelaide. So, let's assume that we got partipants when we went to each place, and that we want to return to one of them for a meeting. In theory, that would be Asia, but AA.COM is showing me suggested flights with travel times of, like, 15 hours (and up). That's more than the travel time I had from Dallas to Brussels, and I schedule international connections concervatively. So, I'm not sure that staying within your continent helps as much as we'd like to think. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Varying meeting venue -- why?
I'm sure other people remember this, but ... I know you meant it in jest, but to be clear to everyone else, qualifying a new venue is a lot of work. One point raised during the plenary is that we might be able to save money if we regularly return to a given venue. Is it possible to quantify those savings based on experience in, say, Minneapolis? My understanding is that Minneapolis kind of fell off the truck due to problems with IETF attendees getting US visas, and not because of other considerations. We've met there a lot in the past 10 or so years. People complained, but not in ways that prevented us from meeting there repeatedly. So if we were going to quantify savings based on return visits, could I suggest that we pick another place to quantify (perhaps Vancouver - we've been there a couple of times lately, and I happen to be sitting in a hotel right now - but anyplace outside the US would work for the concern I was raising). Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Offlist I also believe that the goal of moving the meeting around is to minimize the cost of getting our work done, not to minimize the cost for walk-in attendees. However, to measure this, I suggest we count contributions as we do for IPR purposes: c. IETF Contribution: any submission to the IETF intended by the Contributor for publication as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions described below) and any statement made within the context of an IETF activity. Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: Scott Scott, I couldn't possibly DISagree with this statement (and it actually seems right in principle), but I have no idea how to make it actionable for the IAOC (perhaps Bob is smarter than I am). Am I reading too much into the word count (as if we were toting up the number of times Freddy spoke at the mike in SIPCORE)? Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
HAH... Offlist Awesome. My apologies for asking the offline question onlist. It's like they'll let ANYBODY post here :-( Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
In the case of the 2 BarBOFS I organized at IETF-78, in both cases there were very useful contributions made by people I didn't know and therefore wouldn't have invited. Even if the efforts fail (and one of them was DOA and will not move forward), I am glad to have had the opportunity to get to know more people in an area of interest to me. And that is why I think that these meetings would have been better served if presented as a presentation, rather than a bar BoF. Suppose we had a list of non-WG presentations with a listing like this Title: Tunneling IPSec over HTTP using XML Presenter: Marshall Eubanks Draft: draft-eubanks-ipsec-bloated-transport Abstract: For years now http has not enjoyed the benefits of XML. We are now about to change all that. No longer will IPsec be constrained to efficient formats. I think it's brilliant for us to talk about poster sessions, or lightning talks, at IETF meetings, but we should definitely not confuse that with having a bar BOF in this context... Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Just saying ... too late. http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 and predecessors have been out there for at least a couple of IETFs (like you guys, I'm exhausted, and in my case, too exhausted to check how many IETFs we've had such pages, but I know we had a list in Anaheim). I'm also too exhausted to think of a way to contribute to this conversation, but in a week or two, it might be helpful to resume a conversation Lars started with http://tools.ietf.org/html/draft-eggert-successful-bar-bof-00, submitted late in the week during IETF 77, and which Fred contributed helpful comments to (below). I'm sure the nice people who are bringing bar BOFs to the IETF would appreciate guidance that tells them how to best accomplish their goals ... so it is probably worth providing guidance, as best we can. The successful BOFs RFC (http://tools.ietf.org/html/rfc5434) was very helpful, and a companion document on bar BOFs would likely be helpful as well. Thanks, Spencer, who is going to bed earlier tonight than he has, since last Friday :D If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. In other words, let's make unofficial, ad hoc meetings be formal and scheduled. Fred, like you, I'm delighted to see the activity. However just because there is interest in having formal, scheduled activities that are not qualified to be BOFs, we do not need to have IETF administration support them with extra services. Let's let these self-initiated efforts remain what they are. If they can garner attendees, that's fine. If they can't, better luck next time. Even with the excellent title you suggest, the web page will move these activities down the slippery slope of formality. The way to make a more rational schedule for the week is to schedule less, not more. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selectionprocess
Dave, John, On 7/24/2010 2:24 PM, John Leslie wrote: How can we impose additional experience requirements on some NomCom members without implying that we want their opinions to be considered better? I've been on 3 Nomcoms. Voting members with experience are typically notable, but those without have yet to show anything I'd call deference or intimidation. On the average, IETF participants are each and all rather independent-minded and painfully unintimidated by folks with extensive experience. During a discussion among members, being able to cite experience when offering an opinion helps, but I haven't seen anything that looked like inherently preferential position because a member has more experience. Decisions still require making a good case for a position. I'll be the IAB's liaison to NomCom this year, but I haven't served on a NomCom previously. You're addressing a concern I had (and I don't think I was the only one) about part of the committee deferring to more experienced participants. I hadn't heard anyone saying not a problem in my experience previously. Good to know. Thank you. Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for IESG narrative scribe volunteers
As a former IESG scribe, I would encourage anyone who is interested in understanding the IETF (and especially the IESG) better to volunteer as scribes - and there would be little penalty (from my perspective) in having several more scribes. When I started, Marshall Eubanks and I shared scribe duties and were able to review each other's notes (so neither of us had to capture everything). That was nice. And no one on the current IESG or IAB (because there are a small number of joint sessions) speaks nearly as rapidly as EKR did when I was scribing and he was on IAB. :D For Russ's point about transparency ... one does not have to go any further back than the recent discussions about the IESG view of NEWTRK/ISDs on the IETF discussion list to remember the Bad Old Days when the IESG was a complete black hole to most of us - we didn't know what ADs thought, unless those thoughts made it into the tracker, and there were a lot of thoughts that didn't make it into the tracker. In this specific case, there is no IESG evaluation record and no IESG writeup at all, available from https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/, although the IESG did discuss ISDs at length (so I am told) - and four years later, we're guessing at what the IESG concerns were about a major deliverable from a chartered IETF working group. Russ is the only remaining IESG member from that period, and even Russ can't point to anything that the rest of us can look at. If that sounds like fun, then we don't need narrative minutes, of course. But what if it was your draft? Spencer p.s. Just as a thought exercise, I looked at the most recent official minutes and narrative minutes available from http://www.ietf.org/iesg/minutes/2010/, both for 2010-07-01. As an author, editor, or working group chair, would you rather be looking at The document remains under discussion by the IESG in order to resolve points raised by Russ Housley.* or a.. Amy: discusses b.. Jari: a disagreement on some of the concerns c.. Russ: saw some good point; haven't seen changes d.. Jari: I'll deal with that... Robert, addresses from both SLAC and DHCP, some email discussion, not sure of rules, they seemed to say it can't happen e.. Robert: I envision DHCPv6 server, expecting clients to get DNS from DHCP, could lead to different answers than autoconfigure f.. Ralph: a little contrived, don't see it as possible to have that conflict, either all hosts on link have SLAC, or none; it is possible for some hosts to have both while some have SLAC only, could be two classes of devices in the home, one managed by service provider: in that case, service provider might want special DNS g.. Robert: SIPIT example, is guidance sufficient to ensure that devices at least work h.. Ralph: only places I've heard that is deployment of special devices with additional requirements imposed by service-provider-oriented standards: they should list additional requirements i.. Jari: some language about priorities, warn people it may not work j.. Robert: is it possible to call out ongoing work? k.. Ralph: I'll work on wording; Ron, rogue RA l.. Ron: isn't this risky m.. Ralph: in principle you can always redirect; not a new problem n.. Ron: I'll clear, and discuss this elsewhere o.. Ralph: maybe we haven't discussed low-cost solutions enough p.. Ron: low-cost solutions don't always work, some environments you're just exposed q.. Sean: security ADs worry about this all the time... r.. Russ: Amy, please clear Ron's discuss for him s.. Jari: AD-followup ? Because that's the difference between official minutes and narrative minutes for draft-ietf-6man-dns-options-bis-05. The IESG narrative minutes are posted, whenever available, at http://www.ietf.org/IESG/iesg-narrative.html. Currently, John Leslie is carrying the vast bulk of the load, and Marc Blanchet is providing backup. The IESG would like to recruit at least one more scribe. Other time commitments are not allowing these volunteers to adequately cover all of the IESG meetings. In fact, neither scribe will be able to cover some of the IESG sessions during IETF 78. Volunteers should write to i...@ietf.org by July 19th. We'll keep names confidential, unless people choose to volunteer in public. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-01
I've mentioned this to Russ privately, but it's worth saying it out loud ... Phillip: Obviously, I was not General AD when this happened. However, I was Security AD at the time, so I was involved in the discussions that included the whole IESG. I made my reply to your posting because I want people to realize that there is another side to the story. We need to learn from the history, but we need to act toward improving the future. The IESG spent a huge amount of time on the NEWTRK documents in retreat. The ISD proposal hit the IESG in a very bad way. The ISD proposal required the IESG spend a lot of time that the individuals simply did not have. Further, this came at a very, very bad time. Admin-Rest had consumed way to many cycles. Perhaps the 1-step or 2-step proposals could have been separated from ISDs, but that was not the path that was taken. I do not know the reasons. IESG discussions are now a lot more visible to anyone from the community who cares to look, than they were during any part of NEWTRK. Beginning in late 2005, the IESG has published narrative minutes from every official telechat (details at http://www.ietf.org/iesg/minutes/2010/ for this year). When I served as IESG scribe, there were VERY few unminuted discussions, and they were identified as executive session in the minutes. In addition, I THOUGHT Scott Bradner had requested publication of https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/, and that was the straw that broke the camel's back, but I didn't see any IESG evaluation records for any of the NEWTRK documents, except for the DECRUFT draft (https://datatracker.ietf.org/doc/draft-ietf-newtrk-decruft-experiment/). Speaking only for myself, I didn't know much about what the IESG thought before the NEWTRK session at IETF 63 in Paris, even though I was note-taker for every NEWTRK meeting, and I was an active working group participant (perhaps too active :-). I did not have the understanding about the IESG reaction to NEWTRK that Russ described in his note - and I don't think Russ is mistaken about that reaction. We have significantly improved the transparency of the IESG to the community since NEWTRK was on the docket. I can't tell you that Russ's current proposal will be accepted, but I think I can tell you that members of the community will better understand what the IESG's concerns are, and members of the community will understand which ADs have those concerns, so we can work on resolving them. This isn't a knock at anyone serving on the IESG during the NEWTRK era, all of whom except for Russ have moved on from their honorable service, and certainly not at Brian, who supported IESG narrative minutes as General Area Director when that was still controversial. It was just a different time. We still need to improve, of course, but it's fair to recognize the progress we've made. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-00
OK, we really do seem determined to relive the early 2000s... It seems to me that abolishing the third level is possible, now, because the handling of I-Ds has been enhanced. IMHO, it is an advantage to require some experience before giving an I-D the rank of Proposed Standard. Because I-Ds can change more rapidly and informally than an official standardization round, the early adoption phase can be much more agile that way. However, some I-Ds become RFCs unexpectedly soon, and may ship untested prototypes. If it is agreed that this is rather a shift of maturity levels than simply the abolishment of the last, then some of the current criteria for Draft Standard should be formally shifted to Proposed Standard accordingly. There were proposals for Stable Snap Shots (SSS) from Scott Bradner, and Working Group Snapshots (WGS) from me, Dave, and Charlie Perkins. If I'm remembering correctly, both were intended to say this is stable NOW, but I wouldn't put it in firmware, because we're still getting experience with it, and it could change. Working Group Snapshots (WGS) in http://www.watersprings.org/pub/id/draft-dawkins-pstmt-twostage-01.txt Stable SnapShots (SSS), in http://www.watersprings.org/pub/id/draft-bradner-ietf-stds-trk-01.txt For extra credit, we could implement these with no 2026/2418 changes, if changing 2026/2418 is as impossible as it looks - neither BCP says we CAN'T do WGS/SSS. We probably don't want to restart these discussions without someone summarizing the state of play in previous discussions, because Groundhog's Day was a great movie, but a lousy standards process :D Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
Russ, Thank you/the secretariat for chasing this level of detail down. I suspected the numbers would look something like this, and didn't want to ask for it, but it's much appreciated that you guys did check. With the addition of this information to the previous debate I am supportive of the IESG's message dated 14 May as a stopgap measure, and applaud the IESG for arriving at what is (IMO at least) a fair compromise position that takes into account the concerns expressed by the community. What Doug said. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
Doug, I had also wished for numbers that more clearly translated into impact on who was NomCom eligible (as you requested), but decided not to, simply because I wasn't convinced this would matter enough on who was selected to serve on NomCom, to justifiy spending secretariat time gathering the information. Now that the IESG has changed their proposed policy statement so that people who MIGHT have purchased a day pass thinking that this counted as attending for NomCom purposes, I am OK with not knowing these numbers, and I believe that the IESG is interpreting 3777 in a way that is not unreasonable. Thanks, Spencer These are the number of day passes that were purchased for the meeting listed. Russ On 5/14/2010 6:32 PM, Doug Barton wrote: On 5/14/2010 3:23 PM, Russ Housley wrote: Day Pass History: Hiroshima: 121 Anaheim: 135 Thanks Russ (and Ray). However it's not clear to me if those numbers represent the total number of day pass participants (which they seem to) or if those numbers are an answer to the question I posed below. Would it be possible to get a number from the secretariat of those who have paid full freight for 2 of the last 5 meetings, plus used a day pass for one or more of the other 3? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (FileTransfer Protocol HOST Command) to Proposed Standard
I would like to chime in on this aspect of John's note... I'd also suggest that those who don't like FTP and think we should do no more work on it should not be complaining about this draft, or others, but should be writing an I-D explaining their case. If they can get enough consensus to get that explanation published as a BCP or standards-track document moving FTP to Historic, so be it (although I'd be surprised). If not and their arguments are well-reasoned and documented, I assume that the ISE would be as welcoming to their contribution as he would be to well-written protocol descriptions of existing practices or strongly-motivated proposals. As a new IAB member, I'm becoming disturbed about the number of things that I'm tripping over that everyone knows, but we haven't written down yet. The list of reasons we need to punt FTP seems to be one of those things that we should be capturing as part of our institutional memory. I would be willing to support a document like this in the IAB stream, if that were appropriate, but even if it's not, I think such a document would be a classic example of the reason we need, and have, an Independent Stream. It should find a home. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
Dear IESG, I'm conflicted on this one. I agree that three days at IETF meetings does not a NomCom member make, but I know several people who are very experienced, but who are self-funding, and I can easily imagine someone doing a day pass during a trough in their business cycle. I would be comfortable allowing someone volunteering for the NomCom membership pool to count ONE IETF attended on a day pass - not more than that. Allowing a day pass as one of your three of five doesn't seem dangerous to me, and if you DID attend two tutorials, the reception, the social, and a day of IETF meetings, you certainly could have inhaled some IETF culture. Considering how many NomCom volunteers we get, tuning the algorithm may not affect the membership of a NomCom more than once out of twenty years, of course, so please don't spend much time tuning the algorithm! Thanks, Spencer The IESG is considering the following Statement on the Day Pass Experiment. The IESG plans to make a decision in the next few weeks on a policy statement, and the IESG actively solicits comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. = = = = = = = = RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings. The IAOC is conducting a day pass experiment, making it necessary to augment the NomCom eligibility rules to address IETF participants that make use of a day pass. An update to RFC 3777 to will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative; however, a BCP update for an experiment is overkill. The IESG observes that attending a single day of the IETF meeting is not sufficient for a new participant to learn the culture of the IETF or the qualities that would make an effective IETF leader. Further, ongoing exposure to the IETF standards process is necessary to appreciate the significance and importance of cross-area review. The eligibility requirements of volunteers for NomCom voting member positions are provided in RFC 3777, which includes: 14. Members of the IETF community must have attended at least 3 of the last 5 IETF meetings in order to volunteer. In the context of the day pass experiment, this is interpreted to mean: 14. IETF participants must have attended at least 3 of the last 5 IETF meetings in order to volunteer, and that use of a day pass does not count as IETF meeting attendance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
