Minutes from the Gen-Area meetingSeoul, Monday, March 1st, 2004 - 19:30 to 22:00 Big question: When reforming the IETF, are we working on the right things, or rearranging chairs on the titanic? Scribe volunteer: Matthew J Zekauskas (Thank you!) ========================================== start: changing the way the IETF works, where we are today? (Harald Alvestrand) -- where do we want to be? draft-alvestrand-ietf-mission very general->through->details The IETF wants to be:
not much feedback seen on the lists to the draft. -- today - we are being accused of multiple sins. allow ivory tower academics to block allow commercial interest to control delay stuff for strange reasons but... still working, and delivering The goal of reform is to make sure things work better, and get bookkeeping stuff out of way status page: http://www.ietf.org/u/ietfchair/change-status.html -- ICAR - why this WG Late suprise issue. well known problems, not discovered until late in process. try to work by review earlier in process some people should have read and found it good before wasting time progressing it. The goal of the group is to get experience -- running code. Then make rules. -- NEWTRK - why this WG standards track doesn't make sense -- PROTO team - not a WG how to "fix" the IESG end review process presentation later. -- WG process many rough edges
issue tracking mindset. ones that write stuff down tend to be most successful good minutes is a good thing. EDU team to share experience. what things work doing some experiments - mid-course review is one of them. WG is at the heart of the IETF, so must be careful... -- Good things: just do 'em. (that have limited impact on global structure) mailing list discipline is one such thing -- IESG operations... step carefully "work smarter". -- trying to move quickly and be careful at same time... hard. QUESTIONS Bob Hinden: - think you understate how broken it is. problem of getting stuff thru the IESG, or out of WG into IESG... slow is a big understatement. people are going elsewhere as fast as they can if they can. this is a really serious problem. HTA: avg time 120 days. (wg sub to iesg approval). includes months spent waiting for doc editors.have consensus that there is a problem. more important to solve problem, than to say how bad it is bh: important to accept that it's serious, otherwise not fix. HTA: which way tilting? bh: trying to make things too perfect. In the old days, impl experience that counted. switched it for cross-area review. doing lots of review, input, sec considerations... but no impl considerations under that process. prefer to pub sooner, and get experience. HTA: come back at end.. this is not statement on presentation... bh: think NEWTRK very important. lots of problems relate to that. can't improve process until we get agreement on how change what the process is. really tied together. pekka savola: to slightly disagree w/bob... the IESG has almost always had excellent tput. biggest problem is how to make working group to come to consensus quickly. or if issue raised how to get consensus. once consensus, how to get it into the document quickly. think that's where the problem is. Larry Masinter: didn't answer issue that bothers me... ietf works in area with other stds orgs. maybe more of a problem w/apps... but people making standards in other areas w/o reference to IETF. don't think IETF has done liaison w/other stds groups well. as bob mentioned, people take things elsewhere. that may or may not be to good of internet. HTA: Leslie, care to answer that? leslie daigle: we are working on actual communication mechanisms... larry: nice when figured out that working on something similar and liason. But more concern with outreach, and people involved, and come together with an agreement apriori. are many venues.. Specific effort reports===================================================================== margaret wasserman: EDU team (edu-team@ietf.org) (slides available) -- what is it? -- who is it? -- talked about it a year ago. first public meeting in Vienna. chartered between Vienna and Minneapolis. several areas...
what next? (bof in San Diego) -- ideas? have talked about improving web resources. adding edu support for new ietf roles & processes. other review roles out of ICAR Dave Meyer: great stuff... but not exactly a mentorship program. structured
ed is not way to become the next set of leaders. i don't know if that's
something we envision ever doing... but bringing along the ng of leadership in
any other way. did talk about that at edu team meeting. but mostly about how do it for new people. haven't talked about NG IESG leadership. how prepare people for roles that have now. think that is an issue for IETF. don't know training classes... [[(old) wg chairs training session some of that?]] harald: about OJT: traditionally trained via sink or swim. dmm: that's post-facto. understand what he's saying... how get people to a point where they are prepared for role =================================================================== thomas narten: MPOWR This was a working group proposal... 3 major charter items. -- overall: less feedback then would have expected (for effort that has strong support). so right now, not a sign that there is strong support for it. Not enough work to justify stand-alone wg, maybe do in larger context. not clear what add'l responsibilities are that can't just be done directly, that don't require changes to RFCs. not sure where that leaves us... harald: unless something new comes up, declare this thing as on hold. some of q's in just do it catagory. for the rest... john klensin: respond to t's last question. for a process change/tuning/mod, only IESG can make decision about what has priority. if community makes change w/o IESG, 10 yrs of code that says IESG will ignore... harald: if IESG changes w/o consulting, we're stupid. Pekka Savola: don't recall the specific extent of this proposal... but if not going forward, there are some things that need to go forward. Giving chairs more visibility to document approval process, and more active there, even if not necc. power to block documents or require things... which seems to be most objectionable. HTA: of those examples: ML stuff (authority to block) - everyone agrees, just do. not proposing to drop, but no need for WG to do. having wg chairs more involved in doc processes... proto team working on. so take those out, what's left for MPOWR. pekka: by blocking work, referring to WG chair saying "will not forward unless fixed". ?: can already block (not on mic) ambiguities and disagreements about 2026 and roles. even subsequent to last ietf... his perceived role as chair different than what I thought. room for different interpretations. ?: that's your pleasure (not on mic, didn't hear) (wg serve at pleasure of ad; if don't work right, find new chair) john klensin: my comment not about nature of changes, or whether or not IESG consults community better. strictly, how priorities get determined about whether changes should be considered. that's a meta issue - only the IESG can make 'em. if community and IESG don't agree, only option is somehow getting rid of IESG (member). no good way to appeal. Steve Trowbridge: a set of issues and problems that we can just do. that's great. but some problems that persist that we can't get a handle on/consenus... in that case, who is benefiting from not fixing the problem. usually you will find the answer there. margaret w: address some of pekka's comments: when started out on MPOWR thing, part of one thing. there were 4 parts. 1. internal iesg procedures: continuing in PROTO. 2. part of ML rules. later. 3. more authority to WG chairs. not seen community consensus for that part of proposal (and a bit of push back) so not proceed with that. 4. need to clarify existing roles. but haven't seen energy to write/do. no energy to go forward. Raj Patel(?) at mic: kind of empowerment... don't want block, or just have 100 IESG members. wg chairs help facilitate. perhaps have wg chairs attend iesg telechat. wg chairs have not been involved in work here. I don't see wg chair participation and comments here. (MPOWR, I think). hasn't been effort to get wg chairs more involved. harald: send to list, please ok, now on to some specific proposals for change that are obvious. try to get consensus on "obvious" after each. ==================================================================== margaret: mailing list procedure changes draft-wasserman-rfc2418-ml-update-00.txt draft a few months ago, this is one part people liked, rest not so much. that part is draft above. same authority to manage ML in same way as IETF meetings. ability to control discussion, and ask people to sit down. improve productivity of ML to allow faster resolution (and less procedurally complex) than today. if repeated postings, or rude... today, only way to get them to sit down is to get IESG approval. 2418 sect 3.2: temp suspend, in consultation with AD. relies on WG chair judgement. when warnings, how many warnings, when to suspend. but like any action, it's subject to appeal. issues raised: sequential successions w/o add'l incidents. will fix wording, not intent. - what about AD not available? would like feedback on how to go forward. suggest: update based on discussion, sponsor doc as indiv submission, pub as BCP before IETF60. larry: one favorite saying: no amount of process can substitute for responsibility & judgement. easy to get caught up in details. think about resp & judgement * wg member, responsibility is to not disrupt * wg chair: monitor member * ad: monitor chair recourse is to remove wg chair. don't need a lot of rules, as long as clear that have resp. of exercising appropriate judgement. then #weeks, repeated things not spelled out. tried to not change thing, just Raj patel (indian): think this is trying to intruduce more policing. don't know about incidents that people are being threatened/disruptive. think this is trivial, shouldn't be worried about it. {todd glassey, legal service} margaret: someone contacted my boss and threatened to serve me harald: exceptions. but they have to be dealt with. Raj patel: been on for 5 yrs, have never seen this. continuous off-subject posts despite repeated spencer dawkins: believe agree with raj that not biggest problem that IET F faces... but would like to see it go fwd. margaret(?): have seen lists spin for month or two while ML throttles itself. some groups die. agree not too big of an issue, just thought I could spend a couple of months and solve. spencer: agree son steve trowbridge: hope that fact that can suspend privs has more bene effect than can suspend. aaron falk: don't have a problem with what draft is trying to do, but concerned with precedent. like flexibility & trust in current model ad-wg chairs. this sets precedent where we will start filling in blank spaces in relationship. enumerating detailed authorities of wg chairs. if start to do this with a couple of small areas, people will expect that. go from explicit forbit to explicit allow. margaret: not just filling in. today expressly forbidden for wg chiar to do this. "full iesg approval is needed". everything else wg chair. falk: thanks for clarifications. ? possible solution: just retract 2418? harald: only way to retract is to pub new rfc jck (not on mic): not only way to do it. can ignore. harald: two questions for the room.... good idea, go fwd: 35 people raised their hands bad idea, 1 person We have rough consensus to go forward. John Klensin - draft-klensin-july14 no slides. assume people have read documents. start by using discussion just finished as example. getting ourselves into situation where spending time worrying about process but time spend on process falls into 2 cat
many of us have seen tech orgs taken over by people that don't understand substance but process. don't want to encourage that here. let me distort what happened in MPOWR. when we have consensus to do it +/- details: accellerate in way that doesn't take up meeting time & ml time in large quantities. don't need charter debate. don't need to have a debate on whether timeout period was 29 or 30 days. need to move away from it. need to understand better that perfectly good way of doing engr when know good thing but not sure of rueles try - tune - revise - try something else key proposal of 2 documeents... recognizes something going on for some time, legitimizes and takes adv. thing going on for some time: when IESG doesn't like the way something is working... it changes it. sometimes it changes by ignoring, sometimes by making new rules. then get interesting situation... very elaborate rules on something that happens rarely in recorded history. but, don't document rule because takes time & trouble. then when new things, say "violate rule" person says what rule; iesg says gotcha. need to move away from that. also move away from other extreme: small changes like MPOWR, but need wg for it. and spend weeks debating charter & boundaries for wg. get it out there, let it run, see what happens. if astray, fix it. tell iesg to exert leadership. if controversial and need wg, do it but don't spent much time worrying about it. if no wg, do it, document it, do it later. if can't tell difference, think of a different way which does not mean months spent on charters. in many cases, it's impossible to know the effect of procedural change if we don't try. only results of debate is to waste time & energy... [away from tech work, or can't do tech work.] july 14 draft attempts to expand IESG set of tools for process issues. make tools look more like what stds proc supposed to look like if it were being followed. give iesg tools to say "consensus: let's try". check it out, if works way we want, institutionalize; if not, change, if really broken toss. document as we go, so community knows rules. not really heavy weight. not everything thru model... leaves to IESG whats' important, controversial, ... trend for 6-9 mos for WG charter... possibly worse trend than trend for longer doc cycle times. makes one frightening assumption: IESG behaves according to rules. if IESG decides just another way to pick something to death... we lose. steve trowbridge: flaw with this line of thinking; only way to gain knowledge is w/IETF as stand-alone universe. have others that bring ideas to table via other organization. see rules/procs that avoid problem, bring rules/proc. not neccessarily wg chair here, but elsewhere to bring ideas to table. JCK: 1. agree 2. important to understand difference 3. part of what inspired this was procedural change relative to practices years ago in other organization. experiment: how many people here have been JTC1 conveners, on steering or management of JTC1, liaison on IEEE stds mgmt board? (JCK has been) we can come up with other examples, but... some of us have experience from that perspective looks differently than being in org and being a worker. same from IETF. some of them look differently if on IESG for a while than from the wg. need to understand those differences to understand applicability. what inspired this doc: experience from the stds body out there that invented IT standards. over years, set of processes that we could only aspire to in worst nightmares. year from proposal and when 8 or 9 different groups signed off. and other little details. multiple review panels, process boards, and so on. about 2 yrs ago under industry pressure, org decided to fix itself. new name, new mgmt strucutre. current process: in environment comprable to our areas... area decideds that is a good idea, and issues a call for comments and review. broad community all wg chairs & areas. if no showstopper comments, approved. 7 calendar days. noticed that at the same time as seeing months for IETF charters that had almost no tasks. maybe something wrong. Sam Hartman: think I disagree with strong desire with amount of time spent chartering techical work. understand process for reasons outlined. spending a lot of time out front, if interested in doing and determining charter, and saying no a lot is valuable.. process can take a while, want to know committed before start. ?:second thing that bothers me... certain form of animosity between john and others... can block process, can ignore things now. this proposal might be a good idea.... but only a good idea if IESG buys into it and believes it is a good idea. if not what IESG wants, not going to be useful, even if don't misusue. like to know IESG consensus alongwith community consensuse. 100% in agreement. one of reasons for the impatience that hearing... know that not IESG sign up, useless. with respect to tech chartering: judgement call. leave it to IESG. sometimes yes if better charters. some times don't know how to write charter... let em run, and fire 'em if "off in weeds". leslie dagle: like distinction between chartering tech work and process work. nth time where I've heard takes too long to charter... think not enough distinction between time to charter and time to write document. 2nd is problem. one of things changed now... people are spending work/attention. don't throw out baby with bathwater. agree in general, but details... picking on charter, but it's not the problem. important principle: giving IESG clear mandate and flexibility to do stuff rather than contemplate. if don't understand, make judgement call and move on. margaret: think that the tool in doc... experimental proc tool, is good tool. think that we have it today. but great suggestion to use. think there are other tools too, "just do it", or "requires community discussion"; don't focus on this one. make sure it's not the only tool in box. and judgement call. if IESG were to take tool and use it as only tool, IESG would be stupid. don't think this makes IESG stupid. only thing this proposal does is require documentation rather than falling in unknown. Harald question for the room: the core idea is that of an experimental process (change process and figure out what happened) versus discuss process and get consensus and write it down... is it an userful tool in some cases? [many] no cases where it could be useful? [~0] Conclusion: Consensus that it is an useful tool. Also obvious that it is not only tool (or not always appropriate) pekka: think said model is try something and see what happens. read as propose, get feedback, try and do something. want to make sure the feedback step is there. yes. interesting cases when feedback is loud and disparate. making a decision is good move, usually. rough consensus that we should carry forward/talk more/ to add to toolbox. not sure if this is really a process change. =============================================================================== Avri Doria: suggestion for ombudsman. orginally by ted hardie in a draft. (Presentation available) pulled out to talk about it. Role: review public record on ietf and constitutents in response to complaints made by individuals participant with a complaint - help understand process. why needed...
-- issues
create a 2 yr experiment. to try. --
? (person of scandinavian descent - Swede?): - intriguing idea - need specialized skill, capability to be ffective. esp if mediator. Avri: bitterness with unresolved complaints. think it's important. complaints that don't rise to level of appeal, and think that's a problem. ?: my sense as well. person could be an employee of IETF, or hire on contract as expert mediator. rather than volunteer. Avri: had not thought of that. deeper in role... experiment might indicate warrented. wouldn't suggest ?: if run experiment for year: two people... one volunteer, one hire. Sam Hartman: could be a good idea if right person is chosen ...missed some encourge to not require public report. miscommunication issues get together, and not need formal reporting. finally, one thing to consider: how much does ombudsman talk to next nomcom about people they work with steve trowbridge: employee... interesting thought. was struck by suggestion that someone couldn't do it for 2 yrs. someone can't be effective in 1st year. if not professional, perhaps apprentice. stagger. joel halpern: think something useful under here. not sure what it is, get confused by words. obmudsmen are advocates. mediators listen and suggest resolution. don't think either of those is what you suggest. someone that could make sure concerns addressed using (as much as possible) in informal ways. let me help you (but not do it). Avri: think you're right. not married to words. text quoting, used word ombudsman... dictionary had oversight role, which definitely don't intend. john klensin: presentation inspired thought which didn't have reading doc. margaret: don't really like this idea. not sure if it's presentation. not dead set against... causing more process surrounding situations. mabe make things more formal. when get to formal appeal, no good resolution. people not going to WG chair or AD... do formal role... like civil suit
against leadership. go to them. more facilitor. larry: walked up to consider downside. if two people aren't communicating well... rarely can solve by getting 3rd party in middle. lots of failure cases.. do wrong thing, give wrong advice. ombudsman blurs boundaries. who is responsible? bob hinden: beginning of presentation, good idea... but by end, think downsides as big as benefits. paid employee, .... think useful if someone upset about something, someone that could help point in right direction, rest think hard about . main proposal is what you're saying. steve t: as read/understood... not advocacy, as role of someone that could help coach person that had problem. characterize appropriately, worth solving, and help make judgement about channels to pursue.... ombudsmen in other cases have. yep, that's intent.
Question for the room: do we need an explcit role to facilitate communication for people that work in ietf? yes (perhaps 10% of room) no (perhaps 30% of room) no opinion (perhaps 20%) rough consensus is that we have not been convinced that we need explicit role. jonas ?: comment on proposal... like it. something less than appeal when have problem that is more heavyweight than comment in corner. harald: can always mail chair@ietf.org =========================================================================== PROTO team ideas Margaret: allison on stage in differnet wg right now, will fake it. URL: http://psg.com/~mrw/PROTO-team speed, scalability, openness and effectiveness of doc processing procedures and tools to allow WG chairs to shepherd document thru later stages 1. give WG increased viz & control before talk about that, what do we mean by shepherding resp AD has 3 roles review, approval, shepherding mankin doc to separate, so see shepherding doc process steps last call is approval process resolution of last call comments ------------------------------------------ doc cat herding. aaron falk: doc write-ups. experiment in internet area. pekka: clarification about prototype. if chair says "no" to requester, what happens? might require special review from expertise outside group. cong ctl, or security. or wg chair not comfortable w/review. not a big problem, but not totally comfortable. caveat... pekka; say yes, even tho needs revew because have tried to get review done but failed. my experience: no review, but I couldn't help it. margaret: 2 kinds of q's. chair reminder for duties. some q's do you believe doc needs further review by experts to other areas. flag to AD to get security review. other areas: wg consensus solid? acrimony? potential appeal? communcation between wg chair and ad. not a formal document. formal piece: document write up. synopsis of writeup... summary in ballot for IESG review, also text that goes into document action announcement. 3 peices. abstract. wg summary. protocol quality. implementations, fielded, ... holding q's to end... ------------------------------------------------------------------ proposed pilot: shepherding AD review comments. [Henrik Levkowetz] in order to offload AD workload, increase process transparency "straightforward". AD reads, evaluates and writes comments. returns to chairs for WG responsible chair resolves all ambiguity... responses to mailing list. revising editor fixes, together with consulting wg. issues/text to go with document. AD verifies fixes -------------------------------------------------------------------- Dave Meyer: shepherding discuss comments allow WG chair to follow up on these comments. AD & WG chair agree on comments. iterative process w/responsible AD. WG chair may not understand all comments. chair notifies AD when done. who participates in pilot? duration? tool issues.. right now WG chair must poll tracker write access to tracker? questions: worthwhile? larry: a large and robust industry doing process automation software. what's important to remember is that people participating are either first timers or volunteers (not full time job anyway). so some investment in tools and transparency of tools. people complain that stuff on lists/tracker hard to understand. but we have to understand process before tools to support larry: but if tools might force certain ways through that might need to be changed. who shepherd might not be most important bit, as viz about what should happen next. no one at mic... stunning success or failure. Poll: - agree that makes sense and should continue: most of the room - this is nonsense and should stop: 1.5 w/larry on edge. larry: make sense if some changes in direction happen. a little bit of afraid of turning into high processes. ones used rarely more formal than ones used every day by 50. part of life Summary (Harald) 3 items "just do it", 1 no agreement. On none of issues do we hear "form a wg for it". or discuss it further. may need discussion. no "why fixing problem that doesn't exist". does this make sense? address most important problem? margaret: thing missing from what doing so far, is the inside the wg stuff that we talked about in the beginning. how to get issue tracking used more widely. how to help wg chairs thru tools/process/es/whatever. [stuff from "WG process (2)"] have had aborted things in past, what next? pekka: not much discussion on my favorite two problems. things aren't happening fast enough... from my perspective
many wg docs are revised once per ietf. with that cycle, no way to make productive work. ?: thoughts... editors to work better, always good. some times WG fails to close; arguing over 29 v 31, where decision is most important. but in solving that, know that is consensus org... no gty of answer... problems that don't get solved well here. for areas where it does work, we do better than others. krb wg, no consensus, close down. way IETF should work. use IETF for cases where consensus model produces better specs. for other things, not right forum. not lose that in attempt to get faster results. Q: HOW MANY people have read hardie's alt.consensus draft? of those, who thinks we whould encourage experiments. only a few (1/2 of whole thing). encourage hardie to follow up. thomas narten: been involved w/issue tracking systems, help in some cases... or something like DNS discovery where go on forever and ever pekka: issue tracking usually helps. but to be successful, must have active editor or chairs that subvert process and try to make WG members resolve quickly. if issues are continually raised, iterates, gets old. thomas: issue tracking a culture: making sure people understand, and gets put in doc steve t again: observation from being in other stds group. flexibility is one reason why hard to finish much. penalty for not finishing today is not great. most other groups, have meeting based, roll ballot out by... either get it done by end of week, or 8 mos to get approved. makes people work hard to finish up. more flexible process where not tied to meeting or magic date, easy to slide. at several points. no forcing function to fix all the boring things. dave crocker: when vendors feel pressure to ship and customers feel pressure to buy, ietf can work really fast. harald: got mail today about deadlock on issues. perhaps make case that there is someone that wants issue resolved. what I am hearing... areas that have not addressed are w/in WG. drawing conclusion that we've covered most acute pain problems. have work to do. still problems in WG that we have to deal with. consensus that we have covered things that have to do with doc approval & finsihing yes? (laughter, last option gets the most points) dmm: set of pilots that when complete might be able to answer question. larry: says yes! volunteer to talk to proto team? volunteered a month or two ago (for the team). need to have activities that deal with problem resolution inside wg beyond what deal now. yes? looking at giving wg more tools/training around issue tracking. that's useful. issue tracking issue? volunteers larry< henrick. henrik: yes i think it needs more work. but not start horses when at same time starting a number of others. too much chaos into environment. Conclusions (Harald): things we are doing seem to be sensible, willing to work with those efforts and see results. that's the right thing to do now. a couple of things from just do it catagory got accepted. don't have indication that we should radically change activities we are doing. projects we have will run. see you at plenary.
|