Re: [ietf-privacy] Status?
Hi, Though I might add there there is much utility in discussing these reviews. Discussing them on this list might be an idea. avri On 06-May-14 08:23, Scott Brim wrote: On Tue, May 6, 2014 at 12:57 AM, Christian Huitema huit...@huitema.net mailto:huit...@huitema.net wrote: I wrote 6 of those. I could go on reviewing more stuff, but the lack of feedback made me believe that the exercise was futile... Channeling Stephen maybe ... the goal was not to get immediate feedback or cause immediate changes. That has to happen in the mainline process for modifying or extending RFCs. Instead, the goal is to build up a repository of comments on existing RFCs so that whenever they are revisited (for modification or extension), the people doing so will have a privacy review to refer to. Scott ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] FW: New Version Notification for draft-huitema-perpass-dhcp-identifiers-00.txt
Hi, thanks avri On 16-Mar-14 02:46, Christian Huitema wrote: For what it is worth, the draft about DHCP, identifiers and privacy is now published on the IETF servers. -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Wednesday, March 12, 2014 10:40 PM To: Christian Huitema; Christian Huitema Subject: New Version Notification for draft-huitema-perpass-dhcp-identifiers-00.txt A new version of I-D, draft-huitema-perpass-dhcp-identifiers-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-perpass-dhcp-identifiers Revision: 00 Title: Unique Identifiers in DHCP options enable device tracking Document date: 2014-03-13 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-huitema-perpass-dhcp-identifiers-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-perpass-dhcp-identifiers/ Htmlized: http://tools.ietf.org/html/draft-huitema-perpass-dhcp-identifiers-00 Abstract: Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. This document reviews these options and proposes solutions for better management. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: Last calling draft-resnick-on-consensus
Hi, I think this is an excellent draft and have already sent a pointer of it to colleagues in other organizations as stuff to consider. And although it has been eons since I chaired anything in the IETF, it perfectly matches my recollection of what humming and rough consensus was all about. thanks avri On 6 Oct 2013, at 17:03, Jari Arkko wrote: The document talks about ways in which consensus processes can be successfully run in the IETF. After the last few rounds of versions, I believe this document is ready to move forward. My goal is to publish it as an Informational RFC. It is an explanation of principles and how they can be applied to productively move IETF discussions forward. While there is no change to IETF processes or any presumption that guidance from this document must be followed, I have found the document very useful. It has been referred to numerous times in IETF and IESG discussions. Consensus is hard and many WG discussions have complex trade-offs and differing opinions. I believe having this document become an RFC would help us apply the useful principles even more widely than we are doing today. The abstract says: The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a majority rule philosophy. This is why we engage in rituals like humming instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note (to be removed before publication): This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. The draft can be obtained from http://tools.ietf.org/html/draft-resnick-on-consensus You should see a last call announcement soon, and both me and Pete look forward to your feedback. Jari
Re: Is the IETF aging?
Hi, It may not be line a hiring manager, but all those who have budget can make it a point to make sure some of the younger engineers get to some of the meetings, at least the ones that are relatively local to them. I assume that many of the older participants, have the means to influence the travel lists. For years there have been people working on the gender balance perhaps some focus on the age balance may become appropriate. It was good, though to see that the distribution was not too skewed toward the older participants. As for bringing new work in, doesn't that take a plan for introducing the subject and showing why it is relevant to the IETF community. Although, knowing you, you probably had such a plan. I think that the technical privacy issues, for example, while belonging in the IETF, might still feel strange to some of the traditional engineering participants. So in this case, you may need to promote a slight cultural change that accepts privacy as a requirement as well as the technical challenge of the issue. avri On 2 May 2012, at 15:14, Hannes Tschofenig wrote: Hi PHB, the IETF is not like an enterprise where you can decide (as part of the hiring process) what characteristics your employees should have. In a volunteer organization the offered topics drive the participation. Ask yourself: what you as someone who just finished a university education want to hang around in the IETF to standardize yet another IPv4/IPv6 transition mechanism or to participate in the MPLS-TP discussions? When people suggest new work to the IETF they often see a strange reaction. I remember when Mozilla came to the IETF and proposed to work on the privacy topic Do Not Track. I couldn't find support for doing the work in the IETF. I don't exactly know why people didn't like it but the W3C immediately picked it up and had seen lots of new companies (mostly from the advertising industry) joining the W3C. Ciao Hannes
Re: edu.ietf.org
hi, Yes, the database was moved to a new system and then broke. After some effort James Seng, who is kind enough to host this site has fixed it. I have tested it somewhat and added the XML tutorial. I will add the rest of the tutorial from IETF70 as soon as I can. Please let me know if anyone notices any other problems with this site. thanks for your patience. a. On 4 Jan 2008, at 13:41, Stjepan Gros wrote: Hi! Does anyone know why is edu.ietf.org inaccesible? I'm constantly getting the following error messages: Fatal error: Table './ietfedu/sessions' is marked as crashed and should be repaired query: SELECT u.*, s.*, r.name AS role FROM users u INNER JOIN sessions s ON u.uid = s.uid LEFT JOIN role r ON u.rid = r.rid WHERE s.sid = '37c31323078e0ea9726622aa4a7c821a' AND u.status 3 LIMIT 0, 1 in /home/jseng/vhost/ietfedu/includes/database.mysql.inc on line 97 SG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
removed lots of ccs from this frivolous reply On 16 dec 2007, at 15.15, Ole Jacobsen wrote: I've attended meetings where we had a closed laptop policy during presentations, i find those authoritarian and repressive. unless there is complete unanimity in the room for such a policy it is a very bad idea. incidentally, i always feel so bad for the poor I*s up on the dais with no laptop to hide behind. on the other hand i like the ipv6 experiment - time to sink or swim. and imagine the press if ipv6 fails so publicly. too bad the idea of IP co-existence was never able to actually take hold in the community. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: edu.ietf.org site problems - fixed
Hi, the Edu Team web page (edu.ietf.org) has now been fixed and the presentations can be found both there and on the Agenda page. thanks for your patience. a. On 18 mar 2007, at 20.17, Avri Doria wrote: Hi, As several people have pointed out, we are having problems with the Edu site. I thank everyone who has reported it and wanted to let people know two things: - we are looking into the problem and will get it fixed as soon as possible - as soon as those who gave today's talks give me their slides i am posting them in pdf format to the agenda page: https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=68 Some of them have already been posted. Thanks and sorry about difficulties this has caused people. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
edu.ietf.org site problems
Hi, As several people have pointed out, we are having problems with the Edu site. I thank everyone who has reported it and wanted to let people know two things: - we are looking into the problem and will get it fixed as soon as possible - as soon as those who gave today's talks give me their slides i am posting them in pdf format to the agenda page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Some of them have already been posted. Thanks and sorry about difficulties this has caused people. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom and confidentiality
Hi, To add a tidbit. There has long been a notion of an umbrella of confidentiality in Nomcom. Which means that anyone who has, or is given access, to any of the confidential information has to agree to keep the information confidential. While I have paid very little attention t nomcom over the last few years, I assume this idea is still relevant. I agree with Harald that there is this common assumption of trust given to system administrators. And in fact when as a Nomcom chair, i kept info on my system, there was always the possibility that a company system administrator could see the info and do something with it. I assume the same is true of every nomcom members who receives the email on a work owned computer. I would assume that in addition it being implicit that the tools team folks be trusted to treat things confidentially, that it be explicit that members of the tool team and other administrators of the systems agree to keep nomcom information confidential. I am not looking for an NDA, but perhaps an explicit statement might be useful in assuring people. a. On 7 nov 2006, at 05.37, Harald Alvestrand wrote: I think some of Laksminath's concern is valid. But I think the solution to the problem is simple: Make it publicly known who is on the technical staff that supports the Nomcom, and make it clear that these people: 1) May learn Nomcom information as a side effect of their technical work to support Nomcom 2) Have promised not to reveal that information to others, and have promised not to take any other action based on that information (apart from fixing technical problems) This is analogous to the role of an email postmaster: He *can* read any mail on the system, if he really wants to, but we trust him to not *do* it - or, if he has to during debugging, we trust him to forget what he's read. I trust that Henrik thought this was so obvious it didn't need mentioning. Harald --On 7. november 2006 00:39 -0800 Lakshminath Dondeti [EMAIL PROTECTED] wrote: Fred, When I saw a non-nomcom member having access to what I thought was nomcom-confidential, I was very concerned and now doubt the entire process. I was told that it is secure, but it has not been verified as far as I can tell. At this point, no offense to the tools team, I remain unconvinced. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On 2 sep 2006, at 14.49, John C Klensin wrote: I assume that everything have been done with good faith here but, to paraphrase an off-list discussion, at least some of the community will always have a nagging fear that the reset was motivated by some members of the community believing that a second draw would yield a more favorable Nomcom. I think i agree that it is safe to say that is due to human error, though the consultation with someone who is on the list of those to be considered for renewal does compound the error and put it all at further risk. but i still think it is an error and not an intentional act to subvert the process. On 2 sep 2006, at 17.42, Theodore Tso wrote: On Sat, Sep 02, 2006 at 06:59:36AM -0700, Hallam-Baker, Phillip wrote: The bug here is that the process is insufficiently robust under operator error. That is broke. I think we are in violent agreement that it should be fixed before the next Nomcom. There may be a difference of opinion of how exactly to fix the problem, but I don't think anyone has suggested that we should leave things the way that they are, at least for the next Nomcom. i don't think the process is broken, but the implementation was. and i don't believe this is sufficient reason to reopen the nomcom process. i think the process is clear about what should happen once someone is committed to the 3797 process. what is broken is that the process was, perhaps, not well enough understood and, as is so often the case in the IETF and elsewhere, was followed loosely as opposed to strictly. i do wonder if the previous nomcom chair was consulted in making the decision to redraw - in fact perhaps previous chairs could be a useful resource for the new chair faced with such a dilemma as opposed to representatives of the bodies to be staffed. however, in the sprit of accepting broken implementations (i.e. conservative in what you send, liberal in what you receive) i suggest we wish Andrew luck and let him get on with it. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Hi, I think I am somewhat confused by this discussion. In one place you say: On 14 jul 2006, at 11.04, Fred Baker wrote: The IETF should indeed meet where our participants come from. That was my initial comment (from the mike) on are we from Latin America, Africa, or Antarctica? I think that remains to be shown. and in another: On 14 jul 2006, at 11.55, Fred Baker wrote: from the norht american stats. I would encourage you to compare the european and asiapac meetings, from the proceedings. My observation is that the region/country the meeting happens in tends to be exaggerated. Yokohama, for example, was 1977 folks, of which 1/4 were US and perhaps 40% were Japanese. Seoul was similar. so does this mean that when the meeting is in NA, then the NA population is also exaggerated. Or rather that a large number of participants will come from whatever region the meeting is in (at least for the NA, EU, or Asiapac regions - we have no evidence on LAC or Africa), giving us no objective criteria for weighing one region over another. If this holds, don't we have a parity situation where the meetings should alternate equally between these 3 regions with maybe an occasional meeting in a developing area, like an easy to get to region in Africa or LAC. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: My notes from this morning at breakfast
On 11 jul 2006, at 09.07, Spencer Dawkins wrote: This was NOT intended for general distribution - my apologies... perhaps, but the timely transparency was refreshing. thanks for the error. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17
Hi, I do not wish to enter the substance of this appeal for i am qualified neither by position nor training to adjudicate on the justice of an appeal. But I do want to question one paragraph that has been published on behalf of the leadership of this organization. This questioning is not in relation to the appeal itself, but rather to the acceptability of the statement in itself. On 10 jul 2006, at 14.05, IESG Secretary wrote: Secondly, the IESG believes that the Universal Declaration of Human Rights does not apply to the IETF's internal rules. IETF participants are assumed to be aware of IETF process rules before choosing to participate, and their participation is voluntary. Without making any personal judgement about the correctness of such a hypothetical claim, I could understand an IESG decision that the Universal Declaration of Human Rights (UDHR) did not apply in this particular case. I do not, however, understand a categorical statement to the effect that the IETF, with its rules, is not subject to the UDHR because it is a voluntary association. While the IETF itself is not a signatory to the UDHR, most, if not all, of the nations in which the IESG members live are signatories and the host country of the ISOC corporation, the IETF umbrella, is also a signatory. I believe that in all things we do, we are always subject to the UDHR. And I worry about an organization, especially one I believe in, making a categorical claim that human rights, as defined by the UDHR, do not apply within this organization. We may be here to do technical work, but we should, in my opinion, never leave the responsibilities of humanity at the door. To claim that something so fundamental as human rights do not apply within the confines of the IETF is too all encompassing a statement, and one I don't feel can be allowed to stand without at least a little protest. To quote Eleanor Roosevelt The destiny of human rights is in the hands of all our citizens in all our communities . I think this applies to the IETF community as much as it does to any other community. I hope that the IAB, whatever it may decide on the merits of the appeal in question, will see fit to repudiate the claim that the UDHR does apply to the IETF or its rules. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On revising 3777 as in draft-klensin-recall-rev-00
On 15 nov 2005, at 16.43, Dondeti, Lakshminath wrote:Hi Eliot, The most recent number of nomcom eligible folks is 849, please see https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=446. 20 people out of that isn't all that high. I think I might easily find 10 like-minded people; but 20 makes the burden of proof a bit harder and that sounds good to me. even when i was just 1 person needed to start a recall we never had one, though there may have been cause on occasion. a lot of discussion went on about the number in the nomcom wg. i suggest people go back to the archives before restarting the whole discussion.Furthermore, there have been (rumors of) cases where IESG/IAB members who were purported to be ineffective have been selected again for their positions. (As to why that is is a different story, and is closely related to the same reason why only about 10% of the nomcom eligible folks actually volunteer to be on the nomcom: apathy).or perhaps some people secretly really hope to be put on the iab/iesg. while IETF mythology claims that no one worthy wants the roles, i expect it is not true. though there is the issue that the work load seems to have increased from being a half time job for the iesg to a full time job, and this may make it difficult for independents or people from small companies to contribute the time. this may be a good reason for reforming the iesg, but that is a difficult topic and probably belongs to another thread. it may also be that there is an impression that it is always people from the same core group are selected. this may also be a myth, but may be enough to dissuade people from getting involved in process they may think somewhat futile.finally, i am not convinced that everyone realizes how vital a role nomcom plays in the IETF process, or the fact that it _really_ is open to those outside the core group of IETF.so i think that apathy about nomcom or willingness to serve in I* may be only a small part of the story.a.___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please make sure that you do not run your WLAN in ad hoc mode
On 11 nov 2005, at 13.56, Ole Jacobsen wrote: In 19 days, this very hotel and meeting rooms will be filled with ICANN attendees, most of whom are not technical in our sense of the word. That should be lots of fun :-) It will be interesting to see if ICANN has as much trouble, or IEEE during the intermediate week. I have heard an interesting bit of anecdotal evidence that indicates the situation is worse at IETF meetings then at other meetings. I questioned it, but who knows? a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Faux Pas -- web publication in proprietary formats at ietf.org
On 5 nov 2005, at 02.59, Anthony G. Atkielski wrote: The advantage of PDF is that it preserves the exact appearance of the original document, and that it is designed to be a final format, that is, it is not designed to be editable (and editing PDF is difficult, deliberately so). Also, PDF readers of some kind are available for just about every conceivable platform, and they all work extremely well. I used to be a proponent of PDF usage in the IETF, but I have been informed that there are no PDF readers for the blind. This makes it less then optimal as a universal vehicle. Of course I may be wrong - did not do the research myself, or technology may change. Though I think the pictorial nature of PDF is a barrier. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: technicalities - apologies - wrong list
sorry. wrong list in address. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: from the horse's mouth
On 29 okt 2005, at 15.40, Harald Tveit Alvestrand wrote: Amorality among scientists, engineers, and technologists has gotten the world into a lot of trouble. I prefer to think about the consequences of what I do. I think we all do, and I think it's one of the reasons why I felt Jefsey's accusations of provinciality and blinkeredness to be deeply insulting as well as incoherent. I am not sure what he did other then send 2 pointers to articles. Don't quite understand how this might be insulting. I do think there are two interesting questions: - is the IETF community interested in discussions about the social implications of the technology we develop - is the IETF general list the right place for those discussions. I for one am interested in the topic and think it is important for any tehcnological group to take a view of its social responsibility. But i am not sure that this list is the right place - though I don't mind since I can skip threads that don't interest (or bother) me, but experience shows that not everyone is able to do so. and to some people the topic is irrelevant. So perhaps an ISOC list, or a specific IETF social issues list would be better. At least on such a list everyone would be participating willingly. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: technicalities
On 29 okt 2005, at 23.09, [EMAIL PROTECTED] wrote: And Saddam had WMD, but he used them all up on the Kurds. Darn those Kurds anyway. were these the left over from the ones the US gave him for the war with Iran? a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
I did not mean to say one participant, i meant some participants (though i dropped the 's') and of course accept that that should be a number larger then 3. And I do accept the idea that many of these are subjective and best determined by a trusted entity (IAD/IAOC) and vetted by the community. a. On 17 okt 2005, at 05.59, Sam Hartman wrote: Avri == Avri Doria [EMAIL PROTECTED] writes: Avri - MUST NOT be held in a country whose visa requirements are Avri so stringent as to make it impossible or even extremely Avri difficult for some participant to attend. I think this is too strict. I think visa criteria are an issue, but saying that visa criteria prevent one participant from attending seems way too strict. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
Hi, I can agree with SHOULD and SHOULD NOT, the only problem i had in writing it that way is i could not meet the specification requirement for specifying the conditions under which the requirement would not apply. I did not want to careless create loopholes. My main concern is that these issues be a formal requirement of the community's decision in where we meet. And that they be taken seriously. a. On 17 okt 2005, at 21.50, Brian E Carpenter wrote: Sam Hartman wrote: Avri == Avri Doria [EMAIL PROTECTED] writes: Avri - MUST NOT be held in a country whose visa requirements are Avri so stringent as to make it impossible or even extremely Avri difficult for some participant to attend. I think this is too strict. I think visa criteria are an issue, but saying that visa criteria prevent one participant from attending seems way too strict. More generally, any non-trivial set of MUST NOTs is going to be impossible to satisfy simultaneously. I really don't see how we can go further than should/should not, in practical reality. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
Hi, I think there needs to be some mention of requirements such as: - MUST NOT be held in a country whose visa requirements are so stringent as to make it impossible or even extremely difficult for some participant to attend. - MUST NOT be held in a country with restrictions on freedom of expression, especially if these extend to the blocking of web sites or any other censuring of personal communications. - MUST NOT be held in a country were local participants would be under pressure to support national technical policies on threat of imprisonment or other punitive actions, for their opinions. - MUST NOT be held in a country were local participants would need government approval to attend. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
On 14 okt 2005, at 13.19, Jari Arkko wrote: Freedom of expression is another matter, and would be slippery slope indeed. I think in most cases we would be better off being open and constructive, and helping more people understand what our views are than to refuse contact. I agree, and that is why I tired to include specific issues, though admit that part needs greater specificity. I think the slippery slope can be avoided by designating specific acts that make a site unacceptable. One can safely argue that everywhere censures something, however, some well known practices are more serious then others. Blocked sites, redirected dns, registration and arrest of bloggers etc stand out as things that can be stated specifically and not subject to much interpretation (ok, as anyone who knows me knows, i believe everything is subject to some degree of interpretation). As for being open and constructive, I agree that in principle this is a good goal. however, i beleive it is a goal that exists on its own slippery slope, a slope that ends in appeasement and acquiescence to practices we would prefer not to support. I think a better path to openness is to set a good example and to invite all to participate and to make it easy for them to participate (ref. the visa rules - i also advocate subsidized attendance fees - but that is another issue). a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
Hi, It certainly makes sense to reword it for a pattern of difficulty or exclusion. On any of these criteria, since this is the IETF, it might make sense to subject them to rough consensus criteria. I.e a country that is being considered for a future meeting could be vetted on the IETF list. Or they could be rephrased as guidelines to the IAD and IAOC assuming that they could use a reasonable participant criteria (similar to the reasonable man rule used in jurisprudence) for judging whether sites meet these criteria, with the IETF ready to comment once they make their recommendations. a. On 14 okt 2005, at 15.39, Bill Sommerfeld wrote: On Fri, 2005-10-14 at 11:58, Avri Doria wrote: I think there needs to be some mention of requirements such as: - MUST NOT be held in a country whose visa requirements are so stringent as to make it impossible or even extremely difficult for some participant to attend. An important factor worth stressing, IMHO, is the time required to apply for issue a visitor visa suitable for a short-term visit. If the time required isn't predictable in advance and measureable in small numbers of months, that itself is a barrier to participation. But I might back off on a hair on the phrasing -- several participants? Let's be realistic -- we're talking about government bureaucracy here. Is there any country out there which doesn't occasionally randomly deny or significantly delay granting a visitor visa? A single incident ought not to preclude us from returning. A pattern of exclusion, on the other hand, would be a matter of concern. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On PR-actions, signatures and debate
On 7 okt 2005, at 17.56, Anthony G. Atkielski wrote: It's just possible that the threshold might be higher for some than it is for others. So which threshold is the right threshold? I think that the offense has to be so egregious that invoking such draconian rules is truly a rough consensus - i.e. with very few dissenting voices and for the dissenting voices to be such that their dissent is not well thought out. and while full consensus is rarely possible, it should be as close to full consensus as possible. the IETF of late seems to me to be moving ever closer to a top dominated group where a few voices have control of all decisions and where very little disagreement, especially strong disagreement, is allowed. i think this is a bad trend. to allow for easy suppression of dissent, which always sounds strident to those in power (whether they happen to be in office or not), is, in my opinion a mistake and contributes to that trend. it leads to a behavior mandate of 'be careful of what you say and who you disagree with for it may come back to bite you'. and since there is no real appeal mechanism, except for the very brave, for those who feel abused by the system, the suppression of dissent becomes even more alarming. On 6 okt 2005, at 16.51, Melinda Shore wrote: Messages like I'm for this or I'm against this seem to be taking the form of a vote, when it seems to me that what's probably more appropriate would be an attempt at persuasion. i think that when looking for consensus, it makes sense for multiple people to support the statements of someone else. This is not a vote, but rather an indication that something does or does not have enough agreement to affect a consensus call. my normal attitude on this overly active list is to only comment when i don't see my viewpoint reflected in someone else's comments - in fact that is my attitude vis a vis all IETF lists. but when a storm is gathering and someone must make a consensus evaluation, i think it reasonable to send a 'me too' message and to make that message as short as possible. so in this case i was agreeing that i saw no just cause for a PR action. but if i had seen casue, i would probably have argued for mutual cause given the provocation and counter provocation of the two parties. however, as i argue above, i don't think this rises to the level of requiring application of a draconian response to limit expression. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Anyone not in favor of a PR-Action against Jefsey Morfin
well said. neither am i. a. On 6 okt 2005, at 13.42, Bill Manning wrote: i for one, am not in favor of a PR action against anyone. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Chair, General Area, process and complexity
Hi, in John's formulation, the process work of the general area withers away - or at least moves to a different corner of the world. so what happens to the general area? one suggestion is to axe it. my suggestion would be for that role to be staffed by a generalist who is comfortable with complexity in its many network manifestations. this area could then house those groups that need to deal with complex issues that now often get force fit into the more specific areas. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
publishing names (Re: Complaining (Re: Voting (again))
there have been cases where names were published by the iab or iesg, e,g, in selecting for the iaoc and the isoc bot. while i know it is probably impossible to know how many people refused to be considered because of the publication (don't remember if there was a opt-out of publication opportunity - if so it would be interesting to know how many chose it), what i would be interested in knowing is whether the I* received many comments from a wide cross section of the ietf community on those occasions. thanks a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On 7 maj 2005, at 21.32, Dave Crocker wrote: Let me try the simplest summary possible: If someone has the authority to block the long-term work of a group of IETF participants, they have an *obligation* to take their concerns directly to those participants and engage in a direct process to resolve it. Authority always comes with responsibility. In this case it should simply be that the authority to block a group has a responsibility to interact with that group. Directly. Seems eminently reasonable to me. Even seems practical not to mention good professional etiquette. I find it hard to understand why an AD would not behave this way (though I know it is not the common practice). I have always felt that authority entailed obligations and responsibility. And the more power a position has the more constrained the holder of that position should be in his or her behavior. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: french crypto regulations relating to personal encryption usage by visitors?
On 3 apr 2005, at 04.39, Eric Rescorla wrote: I'm not sure what you think the misunderstanding is. That people are often self-interested and prefer to minimize travel time? I doubt that's a misunderstanding at all. I don't agree with this assessment. I think that if the decision where to continue the North American meeting allocation, just requiring them all to be in Canada, most of the complaints would come from people in the US and not from Europeans even though the US travel time would still be optimized. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Correction to EDU Schedule for Sunday
To IETF meeting participants, The HTML schedule for the Working Group Leadership class on the IETF website is mistaken, whereas the Text version is correct. The class is a two hour session, not a 4 hour session. This will give people the chance to also attend either of the 1500-1700 sessions should they desire. The Schedule for EDU sessions is as follows: SUNDAY, March 6, 2005 1300-1400 Newcomer's Training - Salon E An introduction to the IETF for new or recent IETF attendees. Covers the IETF document processes, the structure of the IETF, and tips for new attendees to be successful in the IETF environment. 1300-1500 Introduction to Working Group Leadership - Salon F This session is designed to help current and future Working Group/BOF chairs, and current and future Working Group document editors, understand the IETF process and what is expected from them. Both the formal requirements and the informal lessons learned from previous Working Group experience are covered. Part of the session is also devoted to how chairs and document authors can work together well to aid the entire process. 1500-1700 Routing, Bridging and Switching: A Tutorial - Salon G This session demystifies the conceptual issues in moving data across multiple hops. We give an overview of, and contrast the functionality of these technologies, including an overview of link state routing (used in OSPF and IS-IS), spanning tree (used in bridging and switching), distance vector (used in RIP), and path vector (used in BGP). 1500-1700 How to Write an RFC - Salon E This tutorial will provide an introduction for newcomers to the RFC series as well as a refresher for experienced RFC authors. It will review the most important editorial policies and formatting rules for RFCs. It will also provide a set of helpful hints to authors about content and format; following these hints will often improve the timeliness of RFC publication and the quality of the resulting documents. It will include a brief overview of the procedures for review and approval of RFCs, both IETF submissions and RFC Editor submissions, and there will be an opportunity to ask questions of RFC Editor staff. thanks Avri Coordinator EDU team ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair
I don't think it is a showstopper and don't think that removing the IAOC char should require a super majority. If the chair serves at the pleasure of the IAOC then the chair should be easily replaceable by the IAOC. I do agree, however, that it should take a majority of the members and not a majority of those present at a meeting to remove the chair. a. On 28 jan 2005, at 04.10, Harald Tveit Alvestrand wrote: Russ raised the issue that 2/3 majority to remove an IAOC chair seems a bit excessive, considering that this requires 6 votes out of 8, with the chair being one of the 8. So the chair + 2 others could hold on to the chair position. Scott mentioned that removing a chair is serious, so we should make sure we don't get into the decision at a meeting with few people present problem, and talked about email voting. Suggested change: Old text (from section 4): The Chair serves at the pleasure of the IAOC, and may be removed from that position at any time by a two thirds vote of the voting membership of the IAOC. New text: The Chair serves at the pleasure of the IAOC, and may be removed from that position at any time by a vote of five of the IAOC voting members. If people disagree with Russ, and think that we SHOULD require six votes, that's easily accomplished: The Chair serves at the pleasure of the IAOC, and may be removed from that position at any time by a vote of six of the IAOC voting members. I don't think that this is a show-stopper issue no matter what the resolution is, but it's nice to have it nailed. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed consensus text: #725 Appealing decisions
I would also prefer that the last paragragh stay in. a. On 28 jan 2005, at 14.13, Sam Hartman wrote: I support this text. I prefer the last paragraph be present but this is not a strong preference. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
I am happy with both as well. thanks a. On 27 jan 2005, at 20.30, Margaret Wasserman wrote: Hi Leslie, I like this formulation. A couple of suggested tweaks, inline: ...and I like your tweaks :-). They make the text much clearer. Thanks. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
Hi Harald, On 26 jan 2005, at 02.23, Harald Tveit Alvestrand wrote: Avri, --On tirsdag, januar 25, 2005 23:44:09 -0500 [EMAIL PROTECTED] wrote: Hi Leslie, This formulation is still of the form that does not give the IETF community a direct voice in the review and appeal mechanisms for the IAOC. I do not understand what you mean by direct voice. Could you explain? As I understand Leslie's formulation, the IAOC has no requirement to process a review from a normal member of the IETF Community unless that request comes from the IAB or IESG. To my mind, this means that the IAOC is answerable to the IAB or IESG and not directly answerable to the IETF Community. When an individual IETF participant makes a review request, it may be ignored. If someone is unhappy at being ignored they may make a request to the IAB or IESG for recognition. This request may be also ignored, with the only recourse to that being an appeal of the IAB or IESG decision to ignore their request. That is, it is only if someone interests the IAB or IESG in their issue that it forces a review. Also the only decision that can really be appealed is the IAB or IESG handling of the request for a review not the decision of the IAOC. I am defining that this as not having direct voice. If what you mean is that the community should have representatives involved in the consideration of the issues, and do not think that the nomcom-selected members, the IESG-selected members and the IAB-selected members of the IAOC are appropriate community representation, I do not see any mechanism short of the way we constitute recall committees that will give you what you want. My issue is not with how the members are appointed to the IAOC. I am fine with that. My issue is whether they are accountable to the community or the community's representatives. As written they are accountable only to the the community's representatives and are thus one step removed from direct accountability to the community. If you think that the community should have the right of complaint, then I think you need to accept some limitation by human judgment on how much effort each complaint can cause. I have not seen any argument that convinces me that those limits should be any different then the limits to judgment that currently exist to complaints, i.e. appeals, against the IAB or IESG. I am basically using the 'running code' argument and asking that the appeal process we currently have be extended to this new IETF management group. If that judgment is to lie outside of the IAOC, it has to be invoked for all complaints to the IAOC (making the system more formalistic); if it is inside the IAOC, it seems reasonable to have some means of overriding it. I, personally see not reason why the IAOC is not directly addressable by the community and does not have a direct obligation to the IETF community. While I am comfortable with the IESG and IAB being the appeal path for the IAOC, I am not comfortable with them being a firewall for the IAOC. I do have a problem with seeing the words that Leslie proposed as fitting your description. As described, it isn't a firewall - it's an override of a safeguard. A firewall protects. As written the IESG or IAB protects the IAOC from the IETF community, which to some extent is being assumed to be a sometimes malicious DOS'ing environment that the IAOC needs to be isolated from. I think this is a fundamental question that differentiates Margaret's formulation from yours. I also think it is a fundamental question that goes back to issues in the problem statement about the current leadership model: too much influence is focused in one leadership group. One benefit of the creation of the IAOC is that it spreads the task of running of the IETF to another group of people. As such, I think the IAOC must be required to respond directly to the community. I don't quite see the logic here - we take tasks that are currently performed in an undocumented and unaccountable fashion and move them into a body that has oversight over them, is selected by the community, is removable by the community, and is (as I see it) normally expected to respond to the community. To some extent those tasks were performed in an unaccountable fashion, and to some extent the Chair's of the IAB and IESG (and maybe the groups themselves) have been the only ones who had any visibility, for some degree of visibility, into them. But that is not really the point. If as you say this is oversight that never occurred before, then I see this formulation as adding more responsibilities to the IAB/IESG, i.e. acting as the oversight body and as the arbiter of the community's voice. And to refer back to the Problem process this is adding responsibility to a group that is already overloaded and which has a scope of responsibility that some feel is already overly large. I guess I dispute, and that really is a fundamental point
Re: #425: Review versus appeal?
Hi Spencer, On 26 jan 2005, at 08.25, Spencer Dawkins wrote: - And last: Even if there is an appeals chain, I don't think the IESG and the IAB should be in it. We are supposed to be selected for the wrong sort of competence. Harald I'm really not trying to muddy the waters here, but - I agree with Harald on this point, for exactly the reason stated, and - this statement seems to be pretty disconnected from the don't have to respond to community appeals, have to respond to IESG/IAB appeals discussion (also in this thread), so I think we're confused on consensus... I am afraid this confuses me. But perhaps it is becasue I think the two subjects of appeal and accountability for review are, and should be, linked. I have difficulty understanding how the IESG and IAB can be responsible for 'enforcing' a review request (Leslie's formulation as I understand it) yet, not have a role in handling appeals. Thinking further this seems to create the following paths - individual request for IAOC review - If no response then make request to IAB or IESG for enforced review (and i am not clear if this a request to either IAB or IESG or to some sort of joint entity. and if it is to either does one just pick the one they are more comfortable with?) - If IAB/IESG refuses to enforce the review request then make a 2026 appeal of the decision of the IAB/IESG - if the appeal is successful then the IAB/IESG makes enforced review request - If the IAOC response is unsatisfactory then what? appeal decision directly to ISOC BoT? do they accept such a responsibility? and who makes the appeal on an enforced review? does the original complainant have the right/responsibility or only the body that required the enforced review. As I indicated above, separating the concept of review request from that of an appeal, an appeal with the possibility of revising a decision, seems to make things more complicated. Unless, of course, the object of the separation is to replace appeals with reviews. And my problem with eliminating appeals, as I have said too often now, is that it makes recall or non renewal the only recourse to correct a problem. This bother me for several reasons: - It is too course a method. 90% of what an IAOC may do could be very satisfactory to the IETf at large with only a few decisions being problematic. But if one must recall the committee to fix a bad decision (I assume that any IAOC can revise the decisions of a prior IAOC) one either sacrifices the good for the bad, or is forced to accept the bad as a price for the good. A finer instrument of correction seems important. - Getting reappointed to a position, or even the absence of recall, becomes 'approval' for all prior decisions, i.e. there is just one undifferentiated moment of accountability for all decisions. - I strongly believe that one of the strengths of the IETF is the direct accountability all of the leadership has to the appeals of the participants. I.e I believe that 2026 accountability is an important part of the IETF and should be maintained for all new organizational structures. Note: If i am alone in my reasoning, I will not stand in the way of the draft going forward (as if i could). So I will probably wait until others of a similar persuasion to mine, if there are any, comment on the issue before making any further comment - unless of course a question is directed at me specifically. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
This set of principles works for me. a. On 26 jan 2005, at 20.40, Eric Rescorla wrote: With that in mind, I would like to suggest the following principles: 1. The IETF community should have input on the internal rules set by the IASA and the IASA should be required to respond to comments by the community on said rules. 2. While the IASA's behavior should be constrained by BCPs (as it will be constrained by the first one) we should in general refrain from enacting specific internal IASA rules changes by BCP. If it is believed that the IAOC is making bad decisions we have a mechanism for unseating them. 3. Decisions of the IAOC should be appealable (following the usual 2026 appeal chain) on the sole grounds that the IASA's processes were not followed. Those decisions should NOT be appealable on the grounds that the decisions were simply bad ones. I recognize that point (3) above is somewhat controversial, so I'll attempt to justify it a bit. The simple fact is that the IASA (both IAD and IAOC) will be constantly making business decisions and if we are to keep the job manageable (and in the case of IAD keep the costs down) they have to know that they will not be constantly second-guessed by the community on what kind of cookies they purchased. If the community feels very strongly that the wrong kind of cookies were purchased then they can ask for a rule demanding chocolate chip, and in the worst case pass a chocolate chip cookie RFC. There's a parallel here in the RFC 2026 appeals process. While the IAB and IESG can review a decision both for process violations AND for technical merit, the ISOC BOT is extremely constrained in that it can only provide limited procedural review (S 6.5.3) Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. It seems to me that this is a good model to follow for IASA. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
hi, I generally agree with these principles with some comments: in (2) I think that the review request need to be addressed to the chair of the respective body. I think the language of 2026 can be adapted as to contents. in (5), I think the appeals should have the full chain of appeals. I know 'at least one level' does include the chain, but I think it is important to be able to appeal all the way to the ISOC BoT. in (6), I agree that decisions that involve contractual obligations mustn't be overturned, but I have a problem with saying that there are no decisions that can be overturned. a. On 25 jan 2005, at 07.29, Margaret Wasserman wrote: So, I'll take a shot at a few things attributes that I think would be good in a review process: (1) I agree with you that we do not want a review process (whether invoked by an individual or by the IAB and IESG) that can overturn a contract award or hiring decision after that decision is made. The current proposed text (I think that the latest was from Leslie) makes the community impotent, without properly restricting the review requests from the IAB/IESG, IMO. [N.B. I do hope that the IAOC will run an open RFP process for most (or all?) contracts, and that the process will include a public comment stage after the IAOC chooses a potential winner, so that there will be an opportunity for the community to raise concerns (if any) before it is too late. Given recent posts, I don't think that the IASA-TT/IAOC is likely to take us in this direction within the next year, but I do hope that we get there eventually.] (2) I think that the review process should be well-enough specified that a person who is not a (past or present) member of the I* could use it. This means that it needs to say where you send a review request, how you unambiguously identify a formal review request and what a review request should contain. This should be at least at the level of detail of the RFC 2026 appeals process (or even a bit more detailed, as folks seem to find that process confusing enough that they don't often get it right). (3) I think that review requests should be limited to situations where the IAOC violates written procedures (their own or the IASA BCP) and/or makes a decision that is against the best interests of the IETF. The request for review should be specific about what procedure was violated and/or how a specific decision runs against the IETF's interests. (4) Personally, I think that any member of the community (and yes, I understand that means the general public) should be able to make a formal review request and expect to get a response from the IAOC within a reasonable time period (~90 days). I do not think the response needs to be a lengthy hearing, or a complex legal document. But, I think that we should have a review process, open to everyone, where a response is mandated. The response could be: We looked into this decision, and we didn't find anything irregular about the decision or about how it was reached. (5) I think that there should be at least one level of escalation possible if the person requesting a review does not receive a satisfactory response from the IAOC (I had suggested that this would go to the IESG). I don't think that the person should have to persuade the IAB or IESG to act on his/her behalf (which is another way in which the current process is really only open to political insiders), I think that the IESG (or whoever we use as the next level lf escalation) should be required to consider the IAOC's response and respond to the escalated review within a reasonable timeframe. (6) I do not think that we want the IAB or IESG (or anyone else) to be able to overturn a decision of the IAOC, only to advise the IAOC that they believe that an incorrect decision was made. Do folks agree with these thoughts? Are there other basic ideas that should be included? Margaret At 11:48 AM +0100 1/25/05, Brian E Carpenter wrote: Sam Hartman wrote: Brian == Brian E Carpenter [EMAIL PROTECTED] writes: Brian Reviewing procedures is fine. Reviewing specific awards Brian isn't, IMHO, which is all I intended my words to exclude. Attempting to undo a specific award once things are signed (or delaying signing) is generally unacceptable. Reviewing a specific award to come to conclusions like we failed to follow our procedures, is definitely problematic but IMHO sometimes necessary. Such reviews need to be handled with great care: some of the data used to make the decision may not be available to the reviewing body and much of the data must not become public. Also, if you conclude that you did follow the wrong procedures in a specific incident but are stuck with the contract because it is already signed, that creates all sorts of bad feelings and potential liability. Exactly. And we need to be sure that the appeals text allows for review of procedures, including the kind of case study
Re: Rough consensus? #425 3.5
On 25 jan 2005, at 08.33, Margaret Wasserman wrote: At 7:54 AM -0500 1/25/05, [EMAIL PROTECTED] wrote: in (2) I think that the review request need to be addressed to the chair of the respective body. I think the language of 2026 can be adapted as to contents. Yes, I agree. That is what I included in my proposed wording (lo these many moons ago), but would also accept other alternatives, as long as it is clear when someone would send a review request and it is clear who is responsible for making sure that it is considered. I think that the Chair is always ultimately responsible for seeing to it that the work of the IAOC, or the IAB or IESG for that matter, gets done. in (5), I think the appeals should have the full chain of appeals. I know 'at least one level' does include the chain, but I think it is important to be able to appeal all the way to the ISOC BoT. Why do you think so? If it is the ISOC BoT that you want in the loop specifically, I suppose that the first level could go there... It seems to me that multi-level appeals in the IETF have not worked very well... I think the multi level escalation works by making sure that the correct level of the organizational layering gets to handle the review. It would be impossible, or at least very complex to say, reviews for topic X go to the IAB while reviews for y go to the the IESG and for Z to the ISOC BoT. And while I think that the ISOC BoT is the reviewer of last resort (as they are today for process issues), I don't believe they necessarily need to be the reviewer of first resort. If multi-level reviews are not working well, I think this is a different problem to be explored separately, but my view is that the IAOC should be slipped into the processes in as compatible a method as possible, and I think that following the same escalation procedures as are currently in existence is an appropriate approach. in (6), I agree that decisions that involve contractual obligations mustn't be overturned, but I have a problem with saying that there are no decisions that can be overturned. So, how would you make the distinction? One of the reasons why I'd rather see no decisions subject to being overturned is that I don't want the IAOC to have an incentive to hide their contract or hiring plans from us until after they are signed (and can't be overturned). I think it is relatively easy to distinguish a contractual obligation from a decision that is not contractual, there is a contract. Now you bring up a good point, what if the IAC uses that as a loophole, and make a decision to not be transparent about contractual plans so that their decisions cannot be altered. This would certainly, to my mind, qualify as a decision where a successful appeal would force a change. I can imagine many other decision that they could make that might also be subject to revision. My problem with making all decisions unchangeable is that it makes appeals toothless, they never can have any real effect. And I believe that this is almost, but not quite, as bad as not having an appeals process as it leave no recourse other then recall or public discontent. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
Hi Leslie, This formulation is still of the form that does not give the IETF community a direct voice in the review and appeal mechanisms for the IAOC. I, personally see not reason why the IAOC is not directly addressable by the community and does not have a direct obligation to the IETF community. While I am comfortable with the IESG and IAB being the appeal path for the IAOC, I am not comfortable with them being a firewall for the IAOC. I think this is a fundamental question that differentiates Margaret's formulation from yours. I also think it is a fundamental question that goes back to issues in the problem statement about the current leadership model: too much influence is focused in one leadership group. One benefit of the creation of the IAOC is that it spreads the task of running of the IETF to another group of people. As such, I think the IAOC must be required to respond directly to the community. a. On 25 jan 2005, at 21.15, Leslie Daigle wrote: 3.5 Business Decisions Decisions made by the IAD in the course of carrying out IASA business activities are subject to review by the IAOC. The decisions of the IAOC must be publicly documented for each formal action. 3.6 Responsiveness of IASA to the IETF The IAOC is directly accountable to the IETF community for the performance of the IASA. In order to achieve this, the IAOC and IAD will ensure that guidelines are developed for regular operation decision making. Where appropriate, these guidelines should be developed with public input. In all cases, they must be made public. Additionally, the IASA should ensure there are reported objective performance metrics for all IETF process supporting activities. In the case where someone questions that an action of the IAD or the IAOC has been undertaken in accordance with this document or those operational guidelines (including the creation of an appropriate set of such guidelines), he or she may ask for a formal review of the action. The request for review is addressed to the person or body that took the action. It is up to that body to decide to make a response, and on the form of a response. The IAD is required to respond to requests for a review from the IAOC, and the IAOC is required to respond to requests for a review of a decision from the IAB or from the IESG. If members of the community feel that they are unjustly denied a response to a request for review, they may ask the IAB or the IESG to make the request on their behalf. Answered requests for review and their responses are made public. Reviews of the IAD's actions will be considered at his or her following performance review. Reviews of the IAOC's actions may be considered when IAOC members are subsequently being seated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
I suppose that I am one of those at the other end of the scale, looking for a solution that allows full and direct IETF community review/appeal. On 23 jan 2005, at 21.35, Spencer Dawkins wrote: I agree with the idea that there are extremes when we talk about our ideas on review, but please don't assume that JohnK and Michael are the only people at that end of the pool... I had assumed that the IETF would let IASA run things with periodic general feedback and rare specific feedback (only in situations when the feedback begins we can't imagine why you ...). The further we move from that end of the spectrum, the less I understand why we need an IASA in the first place. My main reason for supporting the creation of the IAOC specifically, is to offload most of the administrative effort from the IESG/IAB. That is also, incidentally one of my reasons for not wanting the IESg/IAB to be involved in every review/appeal, but only in those that get escalated. The other reason is that it is the IAOC that will be the IETF community's representatives in administration and therefore they should be directly responsible to that community. I agree with the role of IAD becaue I think that job needs to focused in one person. But that does not mean that the person should not be accountable to the community. I know it is harder to do a job with accountability and transparency, but I see any other solution as being problematic for reasons that have outlined earlier. I remain in favor of Margaret's formulation as the compromise position from what I would truly prefer which is for all IAD/IAOC actions and decisions being reviewable in the same manner that the actions and decisions of the ADs, IESG and IAB are currently appealable. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Hi, The IAD is required to respond to requests for a review from the IAOC, and the IAOC is required to respond to requests for a review of a decision from the IAB or from the IESG. If members of the community feel that they are unjustly denied a response to a request for review, they may ask the IAB or the IESG to make the request on their behalf. I still find the lack of direct accountability to the IETF community problematic, though I do realize that this does leave two options open to the community in the case that the IAB or IESG does not decide to honor someone's request for a review: - Protest on the IETF list and at plenary and review in the court of public opinion; i.e resort to public confrontation. - Appeal of a decision by the IESG to not ask the IAOC for a review. I am also assuming that since these appeals would always be procedural they would always be appealable through to the ISOC BoT. So while a bit contorted, there is a path for accountability for the public. The request for review is addressed to the person or body that made the decision. It is up to that body to decide to make a response, and on the form of a response. I do not understand what happens if the IESG/IAB do ask for a review and the IAOC gives what they consider an inadequate response. Is the only recourse at that point to initiate a recall? Or to ask the ISOC BoT to fire the IAD? I am troubled that at the end of the day recall is the only way to redress an error that those in office may commit. Since this is such a large hammer to use, I expect that it will leave the IAOC and IAD free to act with relative impunity. I know we will be reviewing the procedures over the years, but initiating the restructuring without proper mechanisms for accountability seem, to me, to be a mistake. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Hi, In general I am happy with this formulation. Some comments below. On 19 jan 2005, at 09.38, Margaret Wasserman wrote: -- 3.5 Decision review In the case where someone believes that a decision of the IAD or the IAOC either need an extra phrase here or need to change 'believes that' to something like 'objects to' or add the phrase: 'runs counter to the provisions of RFC ... or ... provisions of this BCP ... or maybe: 'is not in the best interests of the IETF' he or she may ask for a formal review of the decision by sending e-mail to the IAOC chair. The request for review is addressed to the IAOC, and should include details of the decision that is being reviewed, an explanation of why the decision should be reviewed, and a suggestion for what action should be taken to rectify the situation. All requests for review will be published publicly on the IAOC web site. It is up to the IAOC to determine what level of formal review is required based on the specifics of the request for review. However, the IAOC is expected to make some public response to a request for review within 90 days of the request, indicating the findings of the review. If the IAOC finds that an incorrect or unfair decision was made, it will be up to the IAOC to decide what type of action, if any, makes sense as a result. In many cases, it may not be possible or practical to change the decision (due to signed contracts or business implications), but the IAOC may choose to make changes to its policies or practices to avoid similar mistakes in the future or may simply wish to acknowledge that a mistake was made and learn from the error. If a person believes that his or her request for review was not handled properly or fairly by the IAOC, he or she may escalate the request to the IESG by sending mail to the IETF chair. The IESG will consider the IAOC's response and may take one of three actions: (1) indicate that the decision was properly reviewed and the IAOC's response was fair, (2) state why the review was improper or unfair and offer advice to the IAOC regarding what type of response or action would be justified, or (3) determine that there is a problem with the rules governing the IAOC and propose changes to this document (or other BCPs) to the IETF community. In this formulation, I would like to see one further possible step or (4) refer the issue to the ISOC BoT for further review. In no case, may the IESG reverse or change a decision of the IAOC or make a direct change to the IAOC's operating policies. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
Hi, Either I don't understand it or I don't agree. I allow that I don't understand it. In the first paragraph it seem like anyone can ask for a decision to be reviewed. In subsequent paragraphs it appears that anyone is limited to IAOC, IAB and IESG members because no one is required to review the questions of anyone other then those in an I*. And while someone can ask for help from the IAB/IESG when their question is ignored, I don't understand why the level of indirection. I think that anyone in the community should be able to go to the IAOC with an issue. I also think it is a work overload issue. In a sense the IAOC is being created to offload the administrative issues from the IAB/IESG. So why buffer them from the public's problems? I think the IAOC should be required to respond to a request for review from the IETf community without requiring IAB or IESG intervention. a. On 13 jan 2005, at 07.27, Harald Tveit Alvestrand wrote: 3.5 Decision review In the case where someone questions a decision of the IAD or the IAOC, he or she may ask for a formal review of the decision. The request for review is addressed to the person or body that made the decision. It is up to that body to decide to make a response, and on the form of a response. The IAD is required to respond to requests for a review from the IAOC, and the IAOC is required to respond to requests for a review of a decision from the IAB or from the IESG. If members of the community feel that they are unjustly denied a response to a request for review, they may ask the IAB or the IESG to make the request on their behalf. Answered requests for review and their responses are made public. I think that should be enough - the IAD and IAOC can route all frivolous requests to /dev/null; the decision of the IESG to not ask the IAOC for a review is an IESG action that can be handled in the usual way; there is no formal I can overturn your decision involved; if the IAOC shows a pattern of replying go away when a review is requested, that becomes a matter of public record, and can be used at nomcom time. Does this seem like a reasonable point on the various scales of concern? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus search: #725 3.4b Appealing decisions
Hi, Thanks for the response. I don't know whether I am in a severe minority on this particular position, and hope that my arguments do not come across as a DOS attack. At a certain point I will accept that rough consensus has passed this concern by. To start, I must admit I have trouble equating an individual or community's disagreement with a decision to a DOS attack, though I do know how disconcerting and distracting an insistent complaint can be. I just don't see equating people's concerns with maliciously motivated attacks, no matter how persistent or obnoxious. I also have no problem believing that the better option in any such disagreement would be to respond early and with due diligence with a public response (accountable and transparent) as opposed to just deleting it because it appears frivolous. I think we need to be very careful in defining an objection as frivolous before having given it due diligence. But once having reviewed an issue and publishing a response, then there would be no reason to re-review, thus avoiding an effect similar to that from a DOS attack. I think this differs from the case of a discussion in a WG since that is an intentional and ongoing exchange of ideas, and traction is often difficult to gauge on a WG list where the majority remains silent. I also think that history has shown us that appeals are relatively rare and generally not frivolous. It is for this reason that I advocate extending the current model of appeal, with the caveats about not voiding contracts etc, to the IAD and IAOC. I think creating the procedure to avoid so called 'DOS attacks' is, in effect, fighting a problem we do not have. a. On 13 jan 2005, at 13.19, John C Klensin wrote: --On Thursday, 13 January, 2005 12:06 -0500 [EMAIL PROTECTED] wrote: Hi, Either I don't understand it or I don't agree. I allow that I don't understand it. Since the model is partially my fault, let me try to explain. In the first paragraph it seem like anyone can ask for a decision to be reviewed. And a sensible IAOC will initiate reviews after any well-reasoned and sensible request, especially one that contains information they didn't consider and should have. If they regularly don't, they should be fired. In subsequent paragraphs it appears that anyone is limited to IAOC, IAB and IESG members because no one is required to review the questions of anyone other then those in an I*. And while someone can ask for help from the IAB/IESG when their question is ignored, I don't understand why the level of indirection. I think that anyone in the community should be able to go to the IAOC with an issue. I, Scott, and probably others are very concerned about denial of service attacks on the IAOC. We have all seen instances (even on the IETF and IPR list in the last few weeks) in which determined people will post small variations on the same complaints over and over again, never noticing that they aren't getting any traction in the community. If the IAOC is required to respond to every similar note with a formal review, it can almost be guaranteed that they will get nothing else done. One way to deal with the problem would be to say no one gets to talk to the IAOC other than the IAB or IESG. That impresses me as fairly bad news for several reasons. So I tried to strike a compromise that says: (1) The IAB and IESG get to initiate requests for review and insist that the IAOC respond. (2) Any member of the community can initiate a request for review. The IAOC gets to decide whether to respond or to hit delete. It isn't explicit in the document, and I don't think it should be, but an IAOC that blows off all such requests without any good reason should be headed for retirement. (3) If the community member doesn't get the expected review, he or she gets to mount a mini-appeal to see if the IESG or IAB can be convinced to endorse the question and demand a review. If the IESG or IAB blows off those requests unreasonably, _they_ ought to be headed for retirement, using normal mechanisms. The text seems consistent with that. If you can suggest better text, I'm sure the editors would be interested. I also think it is a work overload issue. In a sense the IAOC is being created to offload the administrative issues from the IAB/IESG. So why buffer them from the public's problems? I would suggest that if the public has a legitimate problem that the IAOC refuses to address after input and a request from the public, then the IETF has a problem and the IAB and IESG should be aware of it. I think the IAOC should be required to respond to a request for review from the IETf community without requiring IAB or IESG intervention. As I said, the concern is about denial of service attacks. One could, of course, eliminate or reduce that problem by setting up some procedure requiring
Re: #720 and #725 - Appeals and IAD autonomy
On 23 dec 2004, at 20.07, John Leslie wrote: I'm not so much worried about IESG actually _appealing_ the decision on where to get bagels as I am about language which seems to encourage anyone who doesn't like the bagels to _ask_ the IESG to appeal it. I don't understand why it is that the IESG would make the appeals (I know this was the suggestion). I think that appeals should continue to work as they do now. First you appeal to the one who made the decision you don't like, then you escalate it. So if I want to appeal the IAD's decision, i go to the IAD. If I am not satisfied with the answer i go to the IAOC and then up the food chain (staying with the bagel motif) from there. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: No change needed? #717 Open archives of correspondence
ah, back to openness issues. i was wondering when we would get back here. i am fine with this one. a. On 22 dec 2004, at 08.20, Harald Tveit Alvestrand wrote: (note - there are several tickets on openness in general. I am trying to close off this one, because it seems to have been debated enough) Margaret said: Should the same web site also include a record of all written/legal correspondence received by or sent by the IAOC (with sections removed if absolutely necessary for confidentiality)? A long thread resulted (see tracker), in which Leslie quoted from the document: Transparency: The IETF community shall have complete visibility into the financial and legal structure of the ISOC standards activity. In particular, a detailed budget for the entire standards activity, quarterly financial reports, and audited annual financial reports shall all be available to the IETF community. In addition, key contract material and MOUs shall also be publicly available. The IAD and IAOC are responsible for providing regular overviews of the state of the IASA to the IETF community. I think that the consensus on the thread was that the particular requirement being proposed was not warranted; I therefore suggest that we close this ticket with no change to the document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
Mostly ok with me. On 22 dec 2004, at 10.21, Harald Tveit Alvestrand wrote: Suggested resolution: 1) Make a separate section for the appeals stuff in 3.4 (for clarity), so that this becomes section 3.5 2) Change the section to read: If someone believes that the IAOC has made a decision that is clearly not in the IETF's best interest, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. Well, if we follow the current process, they should be able to appeal directly to the IAOC and then escalate it as normal. In cases where appeals concern legally-binding actions of the IAOC (hiring, signed contracts, etc.), the bodies handling the appeal may advise the IAOC, but are not authorized to make or unmake any legally binding agreements on the part of IASA. In cases where no legally-binding actions are at stake, the bodies handling the appeal may nullify the IAOC decision and ask IAOC to restart its decision process. Is it necessary to restart the process. I can imagine cases where it would be sufficient to reconsider something that it had failed to consider. I would suggest substituting reconsider for restart. (mostly suggestion from Margaret) 3) Add the following to the IAOC's role in 3.2: The IAOC will hear and respond to concerns from the community about the activities of the IASA. Even though it is slightly redundant, I would like to see it specifically include a final clause activities of the IASA, including actions by the IAD. Does this make sense, or are we leaning too far in the too many appeals direction? I think it makes sense and that we are not leaning in the 'too many appeals' direction. I believe that the history of appeals, and recalls for that matter, show that they are relatively few, especially when things are running well. The process is new, and there may be a flurry of initial concerns, and these must be handled well for the community to gain confidence in the IASA. The wording 'hear and respond to' should allow for a light weight but due diligence procedure. We will only enter the domain of appeals, in the formal sense of the word, if the community believe that the IAOC is not handling this properly. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #746 Section 3.4 - IAOC decision making
In general I like this formulation with the following comments: editorial: 'non-conflicted' bothers me as a term. I recommend something like ... a majority of the IAOC who are available and who do not need to recuse themselves from the vote. IAOC votes can be taken in person, by teleconference, or by email. As for the condition I would recommend using a quorum rule. e.g. a majority of members. a. On 22 dec 2004, at 15.19, John C Klensin wrote: IAOC decisions are taken by a majority of the non-conflicted IAOC members who are available to vote in person, by teleconference, or by email. However, except in an emergency situation, no decision may be taken with less than condition of the IAOC available to vote. Declaration of an emergency requires a 2/3 majority of the IAOC members available to vote after all members have been notified of the possibility of that action. Of course, the emergency provision, and the assumption that people who had conflicts with the substantive matter would not need to recuse themselves in a vote to declare an emergency, could be abused. But abuse of that variety would, I hope, be a more than sufficient condition for a speedy recall action. condition could be as simple as three or as complicated as some requirement that at least one person appointed by the IETF be included on the majority side. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Conflict of Interest Clause?
I think this is sufficient as well. a. On 22 dec 2004, at 15.22, Harald Tveit Alvestrand wrote: The IAOC will establish and publish rules to handle conflict of interest situations. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Draft version of the IAD job announcement from the IASA TT
On 16 dec 2004, at 04.18, Kurt Erik Lindqvist wrote: -BEGIN PGP SIGNED MESSAGE- The IETF Administrative Entity Isn't it the transition team that is seeking the IAD at this point? is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable to the IETF community. This is a highly visible and very demanding job. Shouldn't we state explicitly that the IAD will be an employee of ISOC? You will be expected to: o Working with the IAOC to document and cater for the administrative requirements of the IETF, IESG, IAB and IRTF. cater is a difficult word that ussually refers to food. I would recommend 'provide for' o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. These should be established in cooperation with ISOC and IASA. This will not be done in isolation. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish procedures for meassuring the performance of these providers. o Eventual mangagement of support staff and contractors. o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. Have we gone so far as to call this job the COO of the IETF? Not only is the IETF not an organization that is structured to have a COO, but i think giving this position the COO designation may be misleading. o Work with our liaison organizations, such as the RFC Editor and the IANA. liaison? o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. What does this mean? o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, Well, i understand how you would measure these thing in a robot, but I am not sure how to determine these capabilities in a human. I think, it might be better to refer to these attributes in human terms; something like the ability to handle a multitude of simultaneous tasks. and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. should we mention that the nature of working together is consensus based? o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency and accountability? as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Should we require experience in running a similar type of operation? Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The Internet Society is based in Reston, Virginia and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. you might want to ask applicants to state salary requirements You must be fluent in spoken and written english. Applicants should forward a resume, references, should ask for a certain number of references and any other relevant materials, with a cover letter explaining why they feel they are the right person for this position written in text or PDF, in an email sent to [EMAIL PROTECTED] Applications will be evaluated starting January
Re: Assuring ISOC commitment to AdminRest
On 12 dec 2004, at 22.40, Dave Crocker wrote: This is probably not what either one of them is thinking about, but I class their exchange as being concerned with the following question: Is the IETF making itself a wholly-owned subsidiary of ISOC, or is the IETF contracting with ISOC to do some services for the IETF. Since I think it is neither of those, I suggest a third possibility are the IETF and ISOC agreeing on a partnership in the administration of the IETF? a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: bcp-02: Section 3.4
Well, A letter of complaint requires no response unless there is something that formalizes the requirement of response. And if there is no procedure indicating that the IAOC needs to pay attention to a letter of complain, that decision, i.e the one to ignore letters of complain, cannot be appealed. So, as I see it, without a formalized process of complaint/appeal of IAD actions we are left with no avenue to deal with problems other then by the yearly nomcom process and the IETF list. On 11 dec 2004, at 22.18, Wijnen, Bert (Bert) wrote: Avri writes: Unless I am missing something in the document, there is no way for a member of the IETf community to formally ask the IAOC to review the decisions of the IAD. Since when would you not be allowed to send an email/complaint to the IAOC ?? I guess you meant to say that there is not formal way to do so, yeah, that is what i explicitly said. but we're all adults and we CAN communicate, can we not? what does being an adult have to do with it? I don't understand. The issue is that there is no way to make the IAOC take notice of the communication. I.e. I do not see why we would need to make a formal procedure for this. Because the lack of formalization leaves the IETF community without a means to appeal decisions. And this decreases the level of accountability. And of the things I thought that were driving the entire AdminRest process was the need for transparency and accountability. And as I understand accountability in the IETF, it involves handling appeals from the IETF community. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: bcp-02: Section 3.4
I tend to agree. As I mentioned in another note, I too am uncomfortable with the appeal procedures. In my case, I am not so much concerned about the ability to overturn decisions, such as contracts that are signed, as I have accepted that allowing this might make the job impossible. But I am concerned about the inability for the IETF community to invoke censure against an IAD who persists in making contractual arrangements that the IETF community finds unacceptable. Unless I am missing something in the document, there is no way for a member of the IETf community to formally ask the IAOC to review the decisions of the IAD. And while it is possible to lodge an appeal against the IAOC for not supervising the IAD properly, I think this may be a bit too roundabout. a. On 10 dec 2004, at 10.55, Sam Hartman wrote: I'm not very comfortable with the appeal text in section 3.4. There isn't a way to overturn decisions and there is no way to appeal decisions because the wrong decision was made. I understand why the current text is there. I understand there are significant concerns about having either of the things I'd like to see in an appeal system. I will try and think of constructive ways of getting better appealability without destroying the IASA's ability to do its job. I'm also not sure how uncomfortable I am with the current text. I know I don't like it, but it's hard to tell how strong that feeling is. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Procedural question on iasa-bcp-02 Last Call (was: Re: Consensus? Separate bank account)
Hi, I agree it does seem procedurally a little skewed. But in thinking about it, I feel that this may not end up a problem as long as one thing happens. That is, if -03 (the 02-bis you refer to) is different in any substantive manner, i.e. other then editorial, it will need to go through a second call before the IESG can decide on it. I.e,, as you said, as soon as an -03 that is substantially different comes out, the LC clock restarts. I think getting this into wider community review, i.e. due to LC, is a good thing to do at this point, even while some of us, myself included, continue to argue on particular points we are uncomfortable with. a. On 11 dec 2004, at 00.26, John C Klensin wrote: Harald, This is purely a procedural question, but my interpretation of the note below and the general support your suggestion has gotten is that the document that is actually being last-called is not draft-ietf-iasa-bcp-02.txt, as identified in the Last Call posted yesterday afternoon, but a hypothetical document, draft-ietf-iasa-bcp-02-bis.txt, which consists of the I-D as modified by assorted comments and agreements on the IETF mailing list or perhaps elsewhere. Is that your intent? If so, I am at least mildly concerned: normally, we have Last Call reviews against stable documents, not documents that are still actively changing, much less virtual documents in which significant changes are being made out of band and in a way that is very hard for someone casually participating in the IETF to track. Do you have a better suggestion? Can we expect a -03 for final review halfway through the Last Call window, with the window being restarted if the changes are significant enough? john --On Wednesday, 08 December, 2004 23:11 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: After all this threading, it seems clear that it would be bad to send out the Last Call today as planned without settling this issue. (Not to mention that the secretariat still hasn't posted version -02) So - scanning back - I find that we have Bert's suggestion for principle that seems to have met with no strong disfavour: Once funds or in-kind donations have been credited to the IETF accounts, they shall be irrevocably allocated to the support of the IETF. (Scott preferred my variant: Donations to the IETF shall be irrevocably committed to the support of the IETF but I don't - this does not cover meeting fees) So I propose the following consensus text - relative to bcp-02, which is visible on http://www.alvestrand.no/ietf/adminrest/draft-ietf-iasa-bcp-0 2.html: a) Add under Principles, section 2.2, between item 4 and 5: Once funds or in-kind donations have been credited to the IETF accounts, they shall be irrevocably allocated to the support of the IETF. b) Note, but DO NOT CHANGE, the following statements from section 5. I believe they address the suggestions Margaret has made for a more detailed specification of money moving into and out of the accounts. 5.2 IETF Meeting Revenues Meeting revenues are an important source of funds for IETF functions. The IAD, in consultation with the IAOC, sets the meeting fees as part of the budgeting process. All meeting revenues shall be credited to the appropriate IASA account. 5.3 Designated Donations, Monetary and In-Kind . ISOC shall create appropriate administrative structures to coordinate such donations with the IASA. In-kind resources are owned by the ISOC on behalf of the IETF and shall be reported and accounted for in a manner that identifies them as such. Designated monetary donations shall be credited to the appropriate IASA account. 5.4 Other ISOC Support Other ISOC support shall be based on the budget process as specified in Section 6. ISOC shall credit the appropriate IASA accounts at least quarterly. 5.5 IASA Expenses The IASA exists to support the IETF. Therefore, only expenses related to supporting the IETF may be debited from the IASA account. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Separate bank accounts
On 8 dec 2004, at 10.20, Harald Tveit Alvestrand wrote: Donations to the IETF shall be irrevocably committed to the support of the IETF. I am not sure I understand what it means. i.e. are you trying to say that donations to the IETF are to be allocated to the IETF's budget and may not be reallocated to another budget? or is there some other content? a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
Seems like a reasonable way to approach it. a. On 3 dec 2004, at 09.19, Harald Tveit Alvestrand wrote: In some other argument in some alternate universe, I said about the appeals issue: I see three alternatives: - Individual decisions of the IAOC cannot be appealed/reviewed by anyone - We invent an entirely new process from scratch just for IAOC matters - We funnel appeals against IAOC into the existing appeals process I dislike the first and second choices (the first because it raises the risk that one will have to resort to the recall control; the second because inventing new process mechanism is *hard*), so by Hobson's choice, I like the third. A theory if decisions of the IAOC can be appealed rather reads: -- If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG. If the IESG, IAB or the ISOC BoT find that procedures are violated, they may advise the IAOC, but does not have authority to overturn or change a decision. -- I remember that 2026 rather carefully circumscribed the power of the appeals process - the IAB can nullify an IESG decision, but cannot make the IESG make a different one. In this case, I think that maybe the process should be even more circumscribed - if the decision is hire an IAD, and the appeal is something like you made the right choice, but did not file proper paperwork, nullifying the hire would make the situation for the newly hired IAD quite confusing. Does this make some kind of sense? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.4
this formulation works for me. thanks. a. On 3 dec 2004, at 11.16, Wijnen, Bert (Bert) wrote: 3.4 Relationship of the IAOC to Existing IETF Leadership The IAOC is directly accountable to the IETF community for the performance of the IASA. However, the nature of the IAOC's work involves treating the IESG and IAB as major internal customers of the administrative support. The IAOC and the IAD should not consider their work successful unless the IESG and IAB are also satisfied with the administrative support that the IETF is receiving. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
While I support the use of open source software whenever possible, it seems too restrictive to mandate it in the BCP on the IASA operation. I am not even sure that this level of detail belongs in this doc at all, though it may belong in a set of recommendations to the IAOC. a. On 3 dec 2004, at 16.37, Henrik Levkowetz wrote: restriction by the contractor. Software should be open source and should be open source ?? It does leave open that it is not mandatory. But it still sounds as a very strong statement. If a contractor develops specific software for us, I'd be OK if we can get it at any time for IETF use, but I am not sure we should require it to be or become open source should we? There are two issues here, one practical and one philosophical. Practically, if we can use it, but don't have the source code, we cannot take it to someone else and ask them to add new functionality. Asking someone else to provide an enhanced version of the tool would mean starting implementation from scratch. But this doesn't mean that the source needs to be open, it means that the IETF needs to have ownership of the source. Philosophically, I would suggest that it might be more in line with the spirit of the IETF to go for open source, and (a different point) I would personally find it desirable. Having IETF-developed software as open source also neatly bypasses any future controversy about ownership, stewardship and whatnot, which I find appealing. I'm not sure I see any strong reasons for us not going this route. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
OK, I am open to the idea. And I suppose that the current appeal mechanisms would allow it. But in that case I do have a problem with making the barrier higher for appeals originating from a non IOAC member. While I can see arguments for not removing an IAOC's member's right of appeal, I don't see any arguments that should give them any greater right of appeal. I.e. I would have difficulty supporting a mechanism that weighed 1 IAOC member versus 10 non members as suggested in your original message. Allow appeals to be made but set some bar for an appeal; perhaps appeals from IAOC members are always accepted, but appeals from the community require say 10 signatures. a. On 3 dec 2004, at 22.44, Sam Hartman wrote: avri == avri [EMAIL PROTECTED] writes: avri And I don't think we want to get into a situation where we avri have one member of the IAOC appealing the actions of the avri IAOC. I do. Or rather in cases where that happens, I'd treat the appeal very seriously. Being reasonable is one of the criteria we use for selecting our leadership. If that leadership still feels a decision is worth appealing even knowing the consequences and pain of such an appeal, then I'm very interested in what they have to say. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
I tend to feel that both the decisions of the IAD and of the IAOC should be appealable. My thinking tends toward thinking that anyone should be able to appeal the decision, or any practice including the accounting practices, of the IAD. I believe we are defining high standards of transparency, as I think we should, but transparency without recourse can be problematic. I think anyone, or perhaps any group of people, should be able to appeal IAD actions to the IAOC. the chain of appeal could be either: a. the normal iaoc-iesg-iab-isoc bot b. iaoc - a joint iab/iesg appeals committee (that excluded iaoc members) set up to hear the appeal - isoc bot c. an abbreviated chain iaoc-isoc bot As for the IAOC, I believe their actions should be appealable as well and should use the same chain as an IAD appeal. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
iasa-bcp-01 - Open Issues - Separate bank accounts
In thinking about this, I think about the fungibility of funds. By having a common account, cash flow issues that might be an issue at various points of the year can be dealt with more easily. For example if funds are earmarked for meeting fees, but collections have not come in time for the year's first meeting, it is simpler to deal with when the funds come from a common account. On the other hand, transparency requires the ability to inspect the accounts that are pertinent to the IETF, its budget vs it projected expenditure vs its actual expenditures. This can, I believe, be adequately handled by so-called 'divisional accounting'. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
iasa-bcp-01 - Open Issues - Startup Phase
Not sure if this refers to what I said in an earlier not about indicating when the process goes into effect. Harald indicated that process BCP approval is indicated by an indication in the ISOC BoT minutes that the BCP was acceptable. I have a slight problem with minutes as the criteria. In boards I have served on, minutes are not formal records until they are approved at a later meeting. This leaves any minuted decision in limbo for another meeting interval. For most decisions this is not a big deal. In this case, I think it is somewhat more significant. Additionally, while the ISOC BoT approves process BCPs, normally they do not place any conditions on ISOC actions. In this case, the IASA BCP does require specific actions from the ISOC BoT. In this case, I think a ISOC BOT approved document, or official resolution, that calls out this BCP and indicates in clear language its agreement with the terms and conditions of the BCP would be helpful. I would suggest a section at the front that says something like:. -- #. Effective date for commencement of IASA The procedures in this document will become operational immediately after this document has been approved by the process defined in BCP 9 and has been affirmed by a Resolution of agreement by the ISOC board of Trustees. -- (alternatively 'immediately after' can be replaced by 'the first day of the following month' or whatever legal/accounting starting point makes sense.) As I said in a previous email, I trust the ISOC to do the right thing, but I prefer to put our trust in the hands of someone who explicitly accepts the terms under which we grant that trust. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Startup Phase
On 2 dec 2004, at 23.00, Scott Bradner wrote: This leaves any minuted decision in limbo for another meeting interval. I do not understand - in all boards I've been a part of the decision is the decision, the minutes just report the decision - it does not matter when the minutes get approved, the decision was made when teh decision was made (e.g. when teh board voted) Yes, and no. It is true that the decision is the decision. But in the Boards I have been involved in, until the minutes are approved at the next meeting, they are not official and thus anything can be disputed and one can (and perhaps not in the ISOC's history but within my experience) argue that a decision the previous meeting was not made properly or not recorded properly. It is a small thing, but on something this important, I would like to see a formal statement of acceptance and not rely on minutes. I do not understand why asking for a response document committing the ISOC BOT to the BCP is a problem? BTW, are the ISOC minutes all public? And how long do they take to show up. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: IASA BCP: Separability
On 1 dec 2004, at 22.35, Sam Hartman wrote: I had sort of assumed this BCP would be the MOU to the extent that one existed. I think that there has to be an equivalent document on the ISOC side as indicated by Geoff, i.e. a document indicating acceptance of the BCP as governing the relationship. And these documents should take effect at essentially the same time. Since, ISOC, under current rules, if I understand them correctly, needs to approve BCP's that change IETF processes, it should be easy for the two documents to be approved, and thus put into effect, simultaneously. Perhaps there should be wording in this document indicating how and when it takes effect. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
seems reasonable to me as well. including the recommended change. a. On 29 nov 2004, at 15.07, scott bradner wrote: Harald suggests: The IAOC, in consultation with the IAB and the IESG, will designate the person(s) to carry out the tasks that other IETF process documents say are carried out by the IETF Executive Director. makes sense to me (I would remove the word other on the 3rd line though) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
Hi, While I agree that the poll should have provided more options, such as: - neither 0 nor c - indifferent - need more info/discussion The fact that it does include a box for comments mitigates the absence somewhat. Especially if in reporting the results, the comments are included as well (without attribution). But yes, a poll needs better design for full validity. a. On 28 sep 2004, at 12.41, Dave Crocker wrote: It is very unlikely that there is any language on this planet that would equate No, I do not wish to state an opinion with I wish to state an opinion but you have no provided a category that covers my opinion. What is normal for surveys that wish to represent the responses of those who are not represented by the provided categories is none of the above. And there is no language on this planet that would equate none of the above with No, I do not wish to state an opinion. More generally, you should review John Klensin's brief comments on this thread. Your response to him suggests that you did not understand his point. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Poll: Restructuring questions
On 24 sep 2004, at 11.20, Harald Tveit Alvestrand wrote: So please - take a look, and tell us that you're listening. http://tools.ietf.org/poll/admin_scenario_alternatives/ I think the poll was a good idea, I hope lots of people take it. I know I had been reading and generally agreeing with some of the folks and the poll is a good forcing function for response. Since my comments are slightly longer then short: I agree with those who are arguing for Scenario 0 and agree with most of the arguments, about complexity and timing. I also believe that a version of C remains a possibility in the future should scenario 0 not work. Though I think it could. I also agree with those who argue that we need an accurate job description for the IAD, and need it soon. I think the startup process seems reasonable. the timing is challenging, but I believe it could be done with lots of hard work and lots of good will. I also agree that 2 IAOC members should be selected by Nomcom - I have argued before why I consider then qualified to chose. I would have argued for more, since I believe that 1/2 of the IAOC should be nomcom selected. However, since I agree with those who argue that the IETF chair and the IAB chair should be voting members of the IAOC, that would mean that 4 of the participants were chosen by a Nomcom process, and that seems a good enough balance. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Functional differentiation and administrative restructuring
Hi John, Thanks for you analysis. It was something I felt lacking and has helping me in my wavering between the absorption into ISOC model and the independent corporate model. I look forward to your analysis of the absorption model. a. On 8 sep 2004, at 01.28, John C Klensin wrote: But, from a risk analysis standpoint, even the abbreviated list above is a pretty long list. If any one of those assumptions (or any of several of those not listed) is not met and things go seriously wrong, the odds of the standards process grinding to a complete halt -- think no meetings, no IESG phone calls, and/or even less functional mailing lists and archives as examples-- are non-trivial. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Functional differentiation and administrative restructuring
Hi John, No problem, my skin is not that thin. As i have tried to explain on the IETF list, i think we need to understand all options including these two extremes - the ones not specifically covered in the mud document. I find the models expressed in the document somewhat incomplete and slightly disingenuous in that they don't discuss the implications of the end of the road - as far as i can tell they hand wave about 'extraneous' results. And while I have never managed to get invovled in the policy part of IETF+ISOC, it is something i care about quite a bit. So if my notes provoke the discussion, even in the form of 'rants', i am satisfied. And thanks for the apology. a. ps. i don't have the negative connotations to absorbtion that you do. I see that as another term for merger, though, since ISOC is the real entity from a corporate point of view, it would constitute an absortion. It is the conditions, as in by-law changes and perhaps MOUs, that determine whether this is beneficial or destructive. On 8 sep 2004, at 09.41, John C Klensin wrote: --On Wednesday, 08 September, 2004 08:53 -0400 [EMAIL PROTECTED] wrote: Hi John, Thanks for you analysis. It was something I felt lacking and has helping me in my wavering between the absorption into ISOC model and the independent corporate model. I look forward to your analysis of the absorption model. Avri, I want to apologize in advance for using your note as the excuse for the rant below. You are certainly not the first person to do this and probably won't be the last; your note just arrived at a convenient time. rant I think we need to be very careful about slapping labels of convenience on options and then getting distracted by what those labels mean. Doing so can really distract from a productive discussion in which information is exchanged.There has been a lot of that sort of distraction, and the associated confusion, going on, since even before San Diego. Absorption is a loaded term. If we are asked how would you like to be absorbed into foo, the answer has got to be no. For me, at least, the recurring image is some rather unpleasant (for the food) digestion process. But, to my knowledge, no one has seriously proposed anything of the sort. Certainly the standards process has not been absorbed. I doubt that the RFC Editor staff would consider themselves absorbed. There are unincorporated organizations in addition than the IETF which have worked closely with ISOC for years and haven't been absorbed either. And independent corporate model, while less loaded semantically (at least for me), is almost equally bad: to the best of my knowledge, no one has really seriously proposed that either, since independent would imply own fundraising and presumably untangling the standards model which is now seriously intertwined with ISOC. As long as critical pieces of those things remain in ISOC's hands, we aren't independent in any of the normal senses of that term. /rant john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
On 7 sep 2004, at 02.13, Brian E Carpenter wrote: [EMAIL PROTECTED] wrote: I'm very puzzled. I though those two extremes were exactly described by scenarios A and D. Perhaps I misread, but while I saw that A and D are the extremes of the scenarios represented to date, I was suggesting is that the extremes not yet discussed are: - full integration into ISOC with the rework of the by-law that accommodates the standard's function. Scenario A tends toward this but does, seem to me, to go all the way. - Creation of a parallel non profit incorporated Standards organization with its own by-laws that is partnered though MOU's with ISOC. Scenario D might evoke this, but since the explanation of this Scenario is so brief, I have trouble understanding its implications. In both I have trouble understanding the full implications in terms of items not within the administrative domain. If A really does equal full integration and D really does equal full independence, then I will stand corrected, though I will remain confused about some of the implications. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
On 6 sep 2004, at 07.31, [EMAIL PROTECTED] wrote: 2. I think that we shouldn't broaden the discussion at this time ( as Avri suggested ), on the grounds of keeping things simple. I understand the desire to keep thing simple and that Carl is attempting a simple fix to a single problem. However, I think that any of the decisions made on a simple fix have possible repercussions for the entire relationship and for the IETF's ability to function as a standards body. It is these that I think need to be understood. This is why I think the full scope of the possible effects should be discussed and understood for all options, including both the 4 compromise solution proposed (A-D) and the more extreme positions of a full merger into ISOC or the establishment of an independent Standards non profit corporate counterpart/companion to ISOC. Currently I think A-D are all in some respect ambiguous relationships that open many questions. I tend to prefer one of the more extreme positions mentioned above, though I can't yet say which of the two i would argue for since I don't fully understand the repercussions of each. That being said, i would also find it reasonable to establish a direction and pick an intermediate route that gave immediate solution to the 'simple' problem problem involved in gaining control of the administrative functions. Whether that intermediate is A or C, would in many ways depend on where we wanted to end up in the end. a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Jabber at ietf60
Are folks using it? a. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Has anybody heard back from the Hotel in Seoul?
Hi, Just as another check point. I sent mine in by email. And on not receiving a confirmation by email, even after a second request, I decided to call them and confirm. They had indeed received it and were able to give me the confirmation number over the phone. Now, since I currently live in Korea, this was a relatively local phone call, so I am not necessarily recommending that everyone call them. But this is an indicator that they are processing the email reservations. a.
Sunday training classes at IETF58
In addition to the Newcomer's training and the security tutorial, the IETF sunday training schedule for Minneapolis will include two new sessions. The first covers the editor's role in working with the WG and in producing RFCs. This is a completely new course. The session is open to both current editors and folks who think they may be interested in taking on an editorship, or co-editorship, at some point in the future. The second is the WG chairs training course. This is an extension of the course that has been given during lunch sessions for WG chairs. This session is open to both current WG chairs and to anyone who thinks they may be interested in chairing a WG. The schedule for the courses is listed below. There is no need to pre-register, just show up. Thanks a. Sunday, November 10, 2003 = 1330-1430 Newcomers Training -- Salon B (Scott Bradner) An introduction to the IETF for anyone who wants to know more about the IETF, specifically recommended for all new or recent IETF attendees. The session covers the IETF history, structure, and standards process. It also provides tips for success in the IETF environment. 1330-1500 Editor's Training -- Conrad C (Avri Doria) Training for current or aspiring IETF document editors. Covers the roles and responsibilities of a document editor, and includes advice on producing a high-quality IETF specification. 1330-1500 Intro WG Chairs Training -- Conrad B (Margaret Wasserman) Introductory training for new or aspiring WG chairs. Covers the role and responsibilities of the WG chair, and includes advice on how to run a WG that is fair, open and productive. 1500-1700 Security Tutorial -- Salon B (Radia Perlman) All IETF attendees need to be aware of the security implications of our design choices. This session offers a basic primer in protocol security, as well as advice on how to write the Security Considerations sections required for all IETF documents.
Re: IETF Sub-IP area: request for input (fwd)
2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors I spoke on this at the Sub-IP area meeting. I beleive that the Area provides focus for a class of problem that is not going to go away. In fact, as the versions of IP are adapted to more underlying structures, including the optical sub-strucutre today and wireless sub-structures tomorrow, there will alwasy be a class of problem that is best categorized as the sub-ip problem. In fact throughout the history of the IETF there have been such issues, e.g. PPP, it is just that they were easily hosted in other areas due to their relative simplicity. As this class of issue grows, however, I think it would benefit from the focus only obtainable its own area. It may even be reasonable to go through the working groups in some other areas and see if some don't fit better into a generic sub-IP area. One further point: Should the WGs be parcelled out to various groups, GSMP should be considered as a candidate for the OM area. Though GSMP was originally in the Routing area this was becasue the MPLS area was there. As it is a management protocol for sub-ip entities I think the best alternate placement for it is the management area. I obviously support it remaining in the permanent Sub-IP area should that be an option. a. -- Avri Doria http://www.sm.luth.se/~avri/
Amended NomCom Volunteer Pool
Hi, As previously announced on the IETF announcement list, the NomCom is to chosen from a list of qualified volunteers. This list was initially published Friday on the IETF announcement list and has been augmented by 2 names tacked onto the end of the list: - 1 whose initial mail did not arrive, but who notified me of the discrepancy before any of the seeds where set. - 1 whose statement was received in time but whose name I inadvertently left off the list. The following is the final list of qualified volunteers which will be used in the drawing. Qualification was based upon verified attendance at 2 of the last 3 IETF meetings (43-Orlando, 44-Minneapolis, 45-Oslo). (Note: The added names (71,72) have not yet been yet been verified by the Secretariat. Should either of them be selected but not be qualified, the selection process will be run an additional step to select an alternate. The effect of this would be the same as having a selected volunteer decline after the selection process. I am sending this out on the IETF discussion list now so that the final headcount can be known before the final seed is set. ) #Name # Name 1. Alec Brusilovsky2. Allyn Romanow 3. Amal Maalouf4. Andrew G. Malis 5. An-Ni Huynh 6. Basavaraj Patil 7. Bernard Aboba 8. Bernhard Petri 9. Bilel Jamoussi 10. Bill Manning 11. Bill Sommerfeld 12. Bob (Robert L.) Fink 13. Bob Hinden 14. Bruce Northcote 15. Charlie Kaufman 16. Cheng-Yin Lee 17. Chris Burke 18. Claudio Allocchio 19. Cynthia Martin 20. Dan Romascanu 21. Danielle Deibler22. Dave Crocker 23. David T. Perkins24. Dorian Kim 25. Doug.Royer 26. Edward Lewis 27. Elwyn Davies28. Erik Guttman 29. Fiffi Hellstrand30. Frank Dawson 31. Graham Travers 32. Greg Minshall 33. Helmut Schink 34. Howard C. Berkowitz 35. Hui-Lan Lu 36. Ian King 37. Igor Faynberg 38. Jeffrey Dunn 39. Jim Luciani 40. Joerg Ottensmeyer 41. John Tavs 42. Josh Cohen 43. Kathleen Nichols44. Kim Hubbard 45. Larry Gabuzda 46. Lixia Zhang 47. Mark Allman 48. Mark Townsley 49. Marshall Rose 50. Martha Zimet 51. Matt Squire 52. Maximilian Riegel 53. Michael Mealling54. Michael W. Condry 55. Nancy M. Greene 56. Pat Egen 57. Patrice Calhoun 58. Paul Ferguson 59. Paul Hoffman60. Pete Resnick 61. Sally Floyd 62. Scott Brim 63. Spencer Dawkins 64. Steve Hanna 65. Steve Waldbusser66. Thomas Hardjono 67. Tony J. Genovese68. Walter Weiss 69. William B. Norton 70. Yakov Rekhter 71. Glenn Zorn72. Rodney Thayer Chair, NomCom --- avri doria +1 617 678 9402
