Re: IAOC: delegating ex-officio responsibility
Hi, So, with more detailed comments below, I think the key thing I'm still struggling with finding a way to articulate is the distinction between: . assignment/(re)delegation of responsibility . offloading work I think the proposal addresses the second. I believe the real problem is that the responsibility for the organization for which the person is ex-officio member is not readily reassigned *from* the person who is in the hotseat. We can agree it would be good if it *could* be done -- it would be good if the IAB Chair (for eg) was not the best/only person to know the nuances of all things going on in the IAB's space. But I don't believe we get there by pulling them out of the loop of administration (with only observer seat status). A few follow-ups, in-line: On 9/20/11 3:05 PM, John C Klensin wrote: --On Tuesday, September 20, 2011 14:16 -0400 Leslie Daigle les...@thinkingcat.com wrote: Hi, I had the comments below on a previous incarnation of how to fix the IAOC because Chairs are overloaded. I have to say -- I don't think the substantive points are addressed in the new proposal, which leaves the Chairs as spectators to the IAOC process. I don't think you can disagree with me that, with no vote (recognized voice) in a committee's work, there's even less possibility to find the hours to keep up with the substance of discussions and thus be able to contribute meaningfully to a discussion when the time comes. As ex-officio non-voting members, with the main responsibility for representing IAB and IESG views and needs resting with someone else, that seems ok to me. At the same time, I think you underestimate the ability of the people involved to read in really quickly if that is necessary/ important. I think I disagree about the likelihood of that working. Often times, the important thing is to detect there is an issue to address. Substantively -- this takes the Chairs off the IAOC, just as the original proposal did, and my comments/confusion/questions below are still current for me. I think I responded to most of these in a different subthread earlier this week. The remarks below are just a quick summary. Original Message Subject: Re: I-D Action:draft-klensin-iaoc-member-00.txt Date: Tue, 01 Sep 2009 18:06:07 -0400 From: Leslie Daigleles...@thinkingcat.com To: IETF discussion listietf@ietf.org CC: John C Klensinklen...@jck.com I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. Leslie, You appear to be assuming that the proposal is somehow removing the IAB and IESG (and ISOC) representation/ presence on the IAOC and Trust. No one has suggested that. I recognize that is not the intent, but I am suggesting that is what will happen in practice. Especially since, at some point, an IAB or an IESG will decide it's politically correct to have a representative who is not currently serving as a member of the IESG or IAB. What has been suggested is that the determination of who is most able to effectively represent those bodies can sensibly be left up to them rather than assuming that the Chairs are somehow endowed with special knowledge and wisdom that no one else shares. Well, speaking only for myself, I think if they were truly wise, they would not find themselves sitting in the chair seat ;-) Rather than thinking the individuals are especially gifted, I believe they have more of the cross-breadth of information than any other committee member AND they wear the responsibility, like no other member does. I think it would be really stupid for the IESG, IAB, or ISOC leadership to put someone on the IAOC who wasn't thoroughly familiar with the thinking in those bodies about IASA issues and competent in the issues the IAOC and Trust address. I think we can trust those bodies to avoid being stupid (except possibly as a tradeoff against worse choices) and don't need to invent rules that ban stupidity. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. Sometimes I feel as if the IETF Chair is tasked with doing a good Superman imitation -- understanding everything, knowing everything, leaping tall buildings... Despite my frequent role as a critic, I'm also impressed with how good a job recent incumbents have done at that. I agree on all points -- and have said in other contexts that I think it's a significant challenge for the IETF that it is more or less held hostage to being able to find such superman every 2, 4 or 6
Re: IAOC: delegating ex-officio responsibility
Hi, I had the comments below on a previous incarnation of how to fix the IAOC because Chairs are overloaded. I have to say -- I don't think the substantive points are addressed in the new proposal, which leaves the Chairs as spectators to the IAOC process. I don't think you can disagree with me that, with no vote (recognized voice) in a committee's work, there's even less possibility to find the hours to keep up with the substance of discussions and thus be able to contribute meaningfully to a discussion when the time comes. Substantively -- this takes the Chairs off the IAOC, just as the original proposal did, and my comments/confusion/questions below are still current for me. Leslie. Original Message Subject: Re: I-D Action:draft-klensin-iaoc-member-00.txt Date: Tue, 01 Sep 2009 18:06:07 -0400 From: Leslie Daigle les...@thinkingcat.com To: IETF discussion list ietf@ietf.org CC: John C Klensin klen...@jck.com I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. The IAB Chair similarly sits at the confluence of all the issues hitting the IAB, and is specifically responsible for tracking them so that they get addressed by the IAB. While the IAB Chair can, in theory, delegate actions on particular topics, it at least used to be the case that some tasks are too tricky or unappealing to get other involvement(too admin, not enough architectural content). And, even with successful delegation of individual tasks, the IAB Chair retains the perspective across all the activities -- technical, IANA, RFC Editor, etc. I'm not going to disagree that the jobs are heavily loaded, and that it's a problem for the IETF that the organization relies heavily on finding a solid candidate for each of these complex positions. However, I think taking them off the IAOC is *not* the place to start. It makes more sense to me to sort out the organizational challenges (of the IESG/IETF, and of the IAB) that cause overloading of these positions, and *then* see what makes sense in terms of identifying IAOC participation. Pulling these positions off the IAOC would succeed in weakening the IAOC, even as it increases the stress levels in the positions as the respective Chairs try to figure out what is going on with the administrative support for the balls they are trying to keep moving. My $0.02cdn Leslie. On 9/19/11 4:05 AM, Olaf Kolkman wrote: Brian, So far you are the only person that has responded with substance. Other feedback was promised but never arrived. I hope to rev this document shortly so that we can finalize it before the Taiwan meeting. I wrote: Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. You responded: And it therefore removes the two Chairs' shared responsibility for decisions of the IAOC and the IETF Trust. I am still far from convinced that this is a good thing. That is correct, under this proposal the chairs don't have voting responsibilities in the IAOC. And while I argue that the chairs can 'steer' as ex-officio I understand that is something you are either convinced off or not. Also, the new section 2.3, which is incorrectly titled but presumably is intended to be IETF Trust membership seems to me to be inconsistent with the Trust Agreement. The Trust Agreement states that the Eligible Persons (to become Trustees) are each a then-current member of the IAOC, duly appointed and in good standing in accordance with the procedures of the IAOC established pursuant to IETF document BCP 101 [as amended]. That doesn't exclude the non-voting members of the IAOC, which is why the IAD is already a Trustee. To change this, the Trust would have to change the Trust Agreement. To be clear, I'm not saying this can't be done, but it can't be ignored either. Yes, it is incorrectly titled. As far as I understand the trust agreement the voting members and the IAD are members
Re: IAOC: delegating ex-officio responsibility
to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-klensin-iaoc-member-00.txt
reduce formal responsibility, or even legal liability, but the IETF Chair should still read everything and debate everything. So I think the workload reduction is illusory. The IAB Chair might be able to step back from some matters, but not when the IAB's oversight areas (IANA and RFC Editor) are concerned. Bottom line: I don't see this change as producing a significant net gain, unless there are arguments that I've missed. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF 75 agenda... Re: Update to the IETF Web Site
I do note, with favour, that it at least implies there will still be text (and html) agendas in the future. Leslie. ... still trying to figure out why there is only a PDF version of the IETF75 agenda on the current website... IETF Chair wrote: For the last 10 months, the IETF Secretariat at the direction of the IAOC and input form the IESG and the IETF community has been working on an overhaul of the IETF web site. The goals for the new site were simple and included: 1) Make it easier for those who are new to the IETF to get involved; 2) Make it easier for experienced community members to access the tools and information they most need; and 3) Ensure that the web site is compliant with W3C standards and accessible to as many people as possible. The revised web site is currently located at www6.ietf.org. Please explore it. One of the first places you may want to start is at the very bottom of the left navigation bar, where you will see the Customize View link. The default view is Normal and if you click on one of the other views you will see slightly different views of the navigation bar and home page. As you move through the rest of the site, the navigation bar will be appear as you selected. On July 6th, the new web site will go live as www.ietf.org. The old site will then be accessible at www4.ietf.org, but the Secretariat will not be updating it any longer, so it will quickly become stale. At the end of August, the old web site will be takes offline. These two months will be used to ensure that all of the web content is available on the new web site and allow any tools that extract content to be updated. Any web site is a work in progress. The IAOC and the Secretariat are committed to continuing to improve the web site. So, please let us send email to the IETF Executive Director, Alexa Morris amor...@amsl.com, with suggestions for further improvements. She is looking forward to receiving your suggestions and constructive criticism. Russ Housley IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
I know Spencer has brought one item of discussion from this last call to the general IETF mailing list, but I'd like to draw attention to the whole document, which, if passed, will make a significant change in IETF practice: the lists of willing nominees for IETF positions will be published publicly. This has been discussed on the ietf-nomcom list: ___ ietf-nomcom mailing list ietf-nom...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-nomcom So, if you're interested, check out the mailing list archives to see how potential issues were discussed. Leslie. Original Message Subject: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP Date: Fri, 5 Jun 2009 16:45:11 -0700 (PDT) From: The IESG iesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Nominating Committee Process: Open Disclosure of Willing Nominees ' draft-dawkins-nomcom-openlist-04.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18213rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: RFC Editor Services Draft RFI
(IAOC) plans to issue a Request for Information (RFI) and a Request for Proposal (RFP) for the performance of the RFC Editor functions beginning in 2010. The incumbent has advised that they do not intend to respond to the RFP. At the request of the IAOC, the RFC Editor Selection Oversight Subcommittee is issuing a draft RFI for community comment. The draft is located at: http://iaoc.ietf.org/rfpsrfis.html The purpose of the RFI itself is to identify potential contractors to provide the RFC Editor services and to obtain feedback from contractors and the broader Internet community on the implementation of the new RFC services model. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Leveraging content and developing voice: new publication(s)?
FYI -- we're still looking for people to complete this survey: If you have thoughts about how the IETF's work could or should be brought to more visibility through such a publication, please feel free to participate in this research study by following this link: http://survey.confirmit.com/wix/p767752991.aspx Quite honestly, we have fairly skewed participation right now. While I haven't (and won't) see the raw data, I'm not surprised to learn we have mostly ISOC member-related people participating so far. We'd greatly appreciate input from a broader range of IETF participants, so we can get a clearer picture of where our mutual interests lie. If you have a few moments to share your thoughts, please do! Thanks, Leslie. (See http://www.isoc.org/tools/blogs/membernews/?p=410 for more info). Leslie Daigle wrote: Among the things that ISOC focuses on is broadening the audience for credible Internet technical information -- IETF material, eg through the IETF Journal; getting Internet model information injected into global public policy discussions etc. As part of an effort to explore whether there might be value in us putting together some new form of publication, we have engaged Rockbridge Associates to conduct research to learn more about our community stays informed about technology, and how ISOC can help. If you have thoughts about how the IETF's work could or should be brought to more visibility through such a publication, please feel free to participate in this research study by following this link: http://survey.confirmit.com/wix/p767752991.aspx Thanks, Leslie. Leslie Daigle Chief Internet Technology Officer Internet Society dai...@isoc.org -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Leveraging content and developing voice: new publication(s)?
Among the things that ISOC focuses on is broadening the audience for credible Internet technical information -- IETF material, eg through the IETF Journal; getting Internet model information injected into global public policy discussions etc. As part of an effort to explore whether there might be value in us putting together some new form of publication, we have engaged Rockbridge Associates to conduct research to learn more about our community stays informed about technology, and how ISOC can help. If you have thoughts about how the IETF's work could or should be brought to more visibility through such a publication, please feel free to participate in this research study by following this link: http://survey.confirmit.com/wix/p767752991.aspx Thanks, Leslie. Leslie Daigle Chief Internet Technology Officer Internet Society dai...@isoc.org -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle les...@thinkingcat.com --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
+1 If it's going to be an IETF Standard, it has to have IETF consensus. This seems consistent with the way individual (i.e., non-WG) submissions are handled through the IESG. Leslie. Pete Resnick wrote: On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote: Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about working groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? http://tools.ietf.org/rfc/rfc4844.txt http://tools.ietf.org/id/draft-irtf-rfcs-03.txt We have (IMO) historically screwed up with regard to IRTF and individual documents and not given them a proper stream to the RFC Editor. The above documents are dealing with that problem. However, for this particular case, I'm with Sam: An IRTF document that is going into the *IETF* standards track is pretty much akin to an any other organizations documents going into the IETF standards track. It may be the case that the IETF and IRTF have a lot more sharing of resources and visibility, than say the IETF and ITU or IEEE, and therefore the hand-off should be quite a bit easier. However, there is no doubt that this is *different* than a WG handing off a document to the IESG for standards track approval. A WG has (ostensibly) been subject to the direct observation of an AD all along and therefore the IESG should have a pretty full understanding of the IETF-wide consensus that has built up around any document coming out of that WG by the time the Last Call comes around. That's not going to be the case for an IRTF (or individual or other external organization) document. Yes, this is a less-than-efficient use of IETF Last Call. But if you want to make efficient use of the process for an *IETF* standards track document, work on it in the IETF. pr -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 2141 - URN Syntax
+1 Leslie. Ted Hardie wrote: At 6:10 AM -0700 10/6/08, Julian Reschke wrote: Rémi Denis-Courmont wrote: On Monday 06 October 2008 15:31:07 ext Julian Reschke, you wrote: Would there be any objections if I tried to update the stuff that needs to be updated (references, ABNF), and submit as Draft Standard? As far as I know, there is no need to resubmit a new version of the document to advance its standard status. See RFC2026. What matters is, it's in Standards Tracks in the first place. Unless there are non-editorial corrections/updates to be made, this looks like a waste of time to me. Well, it has normative references to things that have been obsoleted since and it doesn't use ABNF, so I *do* think it needs a minor freshup. BR, Julian Having reviewed a lot of URN nid requests over the years, I can't say I've ever seen a syntax error that derives from 2141 using something other than ABNF (which is *not* required, simply available). Following the chains to the current version of the URI syntax etc. is also not that hard, so I don't see the need for a change here. If you would like to see it progress, I am sure I can help you find the requisite interoperable implementations to report upon, but, honestly, it seems to be working fine as-is. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
To be clear, and for the benefit of anyone reading this who hasn't tracked attendance at the various bofs discussions, Eric was certainly not the only (then) IAB member who had issues with the proposed approach. And, due to the unavoidable collision of related sessions in our multi-tracked IETF meetings, some of us were unable to attend the CANMOD BoF in person. But, here's what I'm still missing, having caught up with this whole thread: At what point did it become unreasonable to respond to stated technical issues with (pointers to) the resolution of those issues? David Harrington's posts come closest, IMO, to providing those answers, citing the approaches used in the many and varied meetings that have occurred in the interim. I have absolutely no reason to doubt that they were comprehensive. And, given that the known issues were discussed, it would be helpful (as part of this review) to have pointers to some level of succinct summary of what the reasoning was beyond the proponents [continue to] believe this is the right way to go. I'm thinking something like one of: meeting minutes, e-mails, documents... Note that I think this issue/discussion goes well beyond this particular proposed working group. IMO, if the IETF is to be able to have focused WGs while still supporting cross-area review, we need to be diligent in reviewing, addressing, and closing issues in an open fashion. Leslie. --On April 22, 2008 11:16:02 PM +0200 Bert Wijnen - IETF [EMAIL PROTECTED] wrote: Eric, instead of discussing if there was consensus AT THE BOF (we all know that at this point in time we DO have consensus between all the interested WORKERS in this space, albeit that the current consensus was arrived at in further (smaller) meetings, in extensive DT work after the IETF and again after review on NGO list). I propose that you list (again) your (technical) objections to the the current proposal. If all you can tell us is that we need to spend just more cycles on re-hashing the pros and cons of many possible approaches, then I do not see the usefulness of that discussion and with become silent and leave your opion as one input to the IESG for their decision making process. Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric Rescorla Verzonden: dinsdag 22 april 2008 23:14 Aan: David Partain CC: [EMAIL PROTECTED]; ietf@ietf.org Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) At Tue, 22 Apr 2008 23:00:53 +0200, David Partain wrote: Greetings, On Tuesday 22 April 2008 18.10.10 Eric Rescorla wrote: I object to the formation of this WG with this charter. For those who haven't been involved in the discussions to date, Eric has objected to this work from the very beginning, as far back as the first attempt to get a BOF and has continued to object since that time. As such, I'm not surprised that he objects now. Of course, since the issues I was concerned about from the very beginning remain. While there was a clear sense during the BOF that there was interest in forming a WG, there was absolutely no consensus on technical direction. Not surprisingly, I disagree. Well, it's not really like this is a matter of opinion, since the minutes are pretty clear that no consensus calls on the choice of technology were taken, only that some work in this area should move forward: http://www.ietf.org/proceedings/08mar/minutes/canmod.txt The OM community in the IETF has been talking about this specific topic for a long time, both in official and unofficial settings. We've had many hours of meetings where people from all various viewpoints have had hashed out their differences. This all culminated during the last IETF in a rather strong sense of consensus amongst those most interested in this work that it's time to stop talking and move forward, and that YANG was the best way to do that. No, not everyone agreed, but we DO have rough consensus in the OM community and with the APPS area people who were involved that this was a reasonable approach forward. So, what about this consensus thing? Sometimes ADs have to make a call, and my take is that Dan Ron did so. They asked people representing ALL of the proposals to work on a proposal for a charter. We spent a great many cycles doing exactly that. All of the proposals that you saw presented at the CANMOD BOF were very active in the charter proposal discussions and the result is the consensus of all of those people. No one got exactly what they wanted, but I think everyone felt is was a reasonable way forward. So, we have consensus amongst the various proposals' authors. The sum of all this verbiage is that, precisely as I said, there wasn't consensus at the BOF, but that there was some set of rump meetings where this compromise was hashed out. -Ekr
Re: Proposed Revisions to IETF Trust Administrative Procedures
Russ, The IETF Trust was set up as an instrument -- a naturally limited scope. The specific task you identify below (paying attention to items) could reasonably be addressed as Harald suggested. Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. My point, which I think is in line with something John Klensin said earlier, is that even though the current IAOC _intends_ this as a simple administrative change, the fact is it's a structural change that is open to be taken many places by future IAOCs and IETF communities, also of good intent. Given that, it would be nice to understand 1/ that the IAOC has considered this, and 2/ why other solutions are not considered viable. Leslie. P.S.: Also -- good luck with ever having a small meeting -- with 4 Chairs in the room, you'll be looking for end-tables pretty soon ;-) --On April 7, 2008 3:45:16 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
+1 from me. The role of the Trust Chair used to be pretty lightweight: either it still is, and Harald's advice is sound (get clerical help), or it no longer is, and a more detailed explanation of the experienced change would be helpful to the community being asked for comment. Leslie. --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED] wrote: I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transferred to the IETF Trust. I would have to agree with the above, and say further that the the IAB should make sure that the entities responsible for the non-IETF streams are okay with the result. When writing the streams definitions, it was clear that there was a lot of material that was spread across existing documents without clear delineation between IETF or non-IETF documents, let alone further refinement into what has become streams. THat's understandable, historically, but we should be clearer going forward. Breaking it out, as you suggest, would be consistent with that goal. Leslie. While reviewing the documents I tried to determine how the 4 streams currently defined in RFC4844 fit into the framework. Although the stream is not specifically mentioned it is clear that the incoming rights document applies to the IETF Stream. To me it is clear that a contribution to the IAB is explicitly bound by the rules (including the No Duty to Publish rule, that allows for confidential information to be supplied to the IAB), so are contributions from the IAB, i.e. IAB stream document. I conclude this from the fact that IAB is part of the IETF under the definition in 1.e. However, I may be over-interpreting, and the status of the incoming rights for the IAB stream is also not captured. The independent stream document are clearly excluded by section 4 of the document. It is not quite clear where the IRTF stream document live. This could be fixed in a document which defines the IRTF stream. I would think that the document would gain in clarity if it explicitly ties the incoming rights to the streams as defined in RFC4844 and also explicitly calls out that if new streams would be defined those should specifically define if and how rights are transfered to the IETF Trust. --Olaf (no hats) ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: wiki for IETF71 IPv6 experience Re: IPv6 @ IETF-71, especially Jabber
Hi, Sorry -- I've been on a plane most of the last day. The problem yesterday was detected addressed; thanks for letting me know it's recurring. I am told that the problem has been isolated working on a fix. Leslie. Iljitsch van Beijnum wrote: On 5 mrt 2008, at 16:09, Leslie Daigle wrote: As mentioned last week -- the wiki is now accessible: http://wiki.tools.isoc.org/IETF71_IPv4_Outage Right, it was accessible yesterday, but not anymore, at least, for me: the pages don't load. Looks like this is hosted on a 6to4 address. This isn't recommended, because the quality of 6to4 reachability is highly variable. But reachability doesn't seem to be the issue: $ ping6 -c 4 wiki.tools.isoc.org PING6(56=40+8+8 bytes) 2001:720:410:1001:21b:63ff:fe92:9fbb -- 2002:4e2f:6761::2 --- wiki.tools.isoc.org ping6 statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 133.693/133.840/134.106 ms So this looks like a path MTU discovery black hole. According to a traceroute, the web server is terminating the 6to4 link itself and this server is announcing a 1420 byte MSS: 10:54:54.464280 IP6 2002:4e2f:6761::2.http 2001:720:410:1001:21b:63ff:fe92:9fbb.49238: S 2106457901:2106457901(0) ack 809912022 win 5632 mss 1420,sackOK,timestamp 1184434509 542018613,nop,wscale 7 This is consistent with a 1500 byte IPv4 MTU - 20 bytes IPv4 encapsulation = a 1480 byte IPv6 MTU. However, the server is unreachable (from where I'm sitting) for 1480 byte packets: $ ping6 -c 4 -s 1432 wiki.tools.isoc.org PING6(1480=40+8+1432 bytes) 2001:720:410:1001:21b:63ff:fe92:9fbb -- 2002:4e2f:6761::2 --- wiki.tools.isoc.org ping6 statistics --- 4 packets transmitted, 0 packets received, 100% packet loss Can this please be fixed? In general, people use a 1280 byte MTU for 6to4, which nicely avoids the possibility of path MTU discovery black holes. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
wiki for IETF71 IPv6 experience Re: IPv6 @ IETF-71, especially Jabber
As mentioned last week -- the wiki is now accessible: http://wiki.tools.isoc.org/IETF71_IPv4_Outage Thanks, Leslie. Leslie Daigle wrote: Hi, To the basic question of the IPv4 outage -- preparations are indeed underway, to implement it as Russ described on 12/22/2007[1]. Early next week, there will be a wiki page accessible specifically for our event, providing more detail and more pointers. In the meantime, if you have specific comments, you can send comments to the team Russ set up[2]. In the meantime, NANOG and APRICOT have had similar events. You can see some of the data captured here: http://www.civil-tongue.net/grandx/ and some writeups: http://www.networkworld.com/community/node/25276 http://www.circleid.com/posts/82283_ipv6_hour_ipv4_switched_off/ Leslie. [1] [On December 22, 2007, Russ Housley wrote:] Following the mail list discussion, we have considered several different configurations for achieving the desired network experiment environment. It is important that everyone have adequate opportunity for advance configuration, and it is important that severe impact on other network resources at the meeting venue be avoided. With these goals in mind, we intend to add an additional IPv6-only subnet, with a different SSID on the wireless network. The SSID will include some clever name that includes the string v6ONLY. This SSID will be available on all the wireless access points throughout the venue for the entire week. Everyone is encouraged to try using this network well before the plenary session. Neighbors and friends are encouraged to help each other debug problems, and the kind folks at the help desk in the Terminal Room will also be happy to assist with any configuration challenges, IPv6-related or otherwise. [2] [EMAIL PROTECTED] Iljitsch van Beijnum wrote: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because I've had an IPv6 mail server for years and a WWW proxy that allows IPv6-only hosts to get access to the IPv4 web is fairly trivial to set up (tip for XP users: XP can't do DNS lookups over IPv6, use Firefox and configure it with the IPv6 address of the proxy), my preperation for this has been mostly getting Jabber to work over IPv6. A while ago I managed to find a public Jabber server that is reachable over IPv6 (amessage.de with some other domains pointing to the same server). Unfortunately, the client I generally use, Apple's iChat, does support Jabber over IPv6 when there is IPv4 connectivity, but when the system has no IPv4 address it says that you're not connected to the internet and doesn't try to connect over IPv6. Recently I thought this was fixed but it turned out that the Parallels Desktop virtualization enviroment sets up a bunch of virtual interfaces with private addresses, which is enough for iChat to work over IPv6. Anyway, I started looking for Jabber clients that support IPv6. Most don't, but there are so many Jabber clients that there is actually a choice of ones that do. Unfortunately, none of them could connect to the jabber.ietf.org rooms. I first thought this was because of the clients, so I didn't keep a list of clients that support IPv6. But it turned out that this is a problem with my iljitsch at amessage.nl account on the amessage.de server, which doesn't seem IPv6-related. So... does anyone know a place to obtain a Jabber account that's usable over IPv6? I assumed psg.com would be a good candidate, but even though psg.com has a record, jabber.psg.com doesn't. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 @ IETF-71, especially Jabber
Hi, To the basic question of the IPv4 outage -- preparations are indeed underway, to implement it as Russ described on 12/22/2007[1]. Early next week, there will be a wiki page accessible specifically for our event, providing more detail and more pointers. In the meantime, if you have specific comments, you can send comments to the team Russ set up[2]. In the meantime, NANOG and APRICOT have had similar events. You can see some of the data captured here: http://www.civil-tongue.net/grandx/ and some writeups: http://www.networkworld.com/community/node/25276 http://www.circleid.com/posts/82283_ipv6_hour_ipv4_switched_off/ Leslie. [1] [On December 22, 2007, Russ Housley wrote:] Following the mail list discussion, we have considered several different configurations for achieving the desired network experiment environment. It is important that everyone have adequate opportunity for advance configuration, and it is important that severe impact on other network resources at the meeting venue be avoided. With these goals in mind, we intend to add an additional IPv6-only subnet, with a different SSID on the wireless network. The SSID will include some clever name that includes the string v6ONLY. This SSID will be available on all the wireless access points throughout the venue for the entire week. Everyone is encouraged to try using this network well before the plenary session. Neighbors and friends are encouraged to help each other debug problems, and the kind folks at the help desk in the Terminal Room will also be happy to assist with any configuration challenges, IPv6-related or otherwise. [2] [EMAIL PROTECTED] Iljitsch van Beijnum wrote: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because I've had an IPv6 mail server for years and a WWW proxy that allows IPv6-only hosts to get access to the IPv4 web is fairly trivial to set up (tip for XP users: XP can't do DNS lookups over IPv6, use Firefox and configure it with the IPv6 address of the proxy), my preperation for this has been mostly getting Jabber to work over IPv6. A while ago I managed to find a public Jabber server that is reachable over IPv6 (amessage.de with some other domains pointing to the same server). Unfortunately, the client I generally use, Apple's iChat, does support Jabber over IPv6 when there is IPv4 connectivity, but when the system has no IPv4 address it says that you're not connected to the internet and doesn't try to connect over IPv6. Recently I thought this was fixed but it turned out that the Parallels Desktop virtualization enviroment sets up a bunch of virtual interfaces with private addresses, which is enough for iChat to work over IPv6. Anyway, I started looking for Jabber clients that support IPv6. Most don't, but there are so many Jabber clients that there is actually a choice of ones that do. Unfortunately, none of them could connect to the jabber.ietf.org rooms. I first thought this was because of the clients, so I didn't keep a list of clients that support IPv6. But it turned out that this is a problem with my iljitsch at amessage.nl account on the amessage.de server, which doesn't seem IPv6-related. So... does anyone know a place to obtain a Jabber account that's usable over IPv6? I assumed psg.com would be a good candidate, but even though psg.com has a record, jabber.psg.com doesn't. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Opportunity Re: IPv4 Outage Planned for IETF 71 Plenary
I wonder if we could hive off a thread to focus on some constructive possibilities of this opportunity? E.g., sites known to support IPv6 access? The background work here will clearly have to address issues such as useful DNS resolution ( in the root and/or server hacks), DHCPv6, etc, but assuming those issues get resolved, can we construct some plan for constructive use of the time? From my perspective, the worst case here is that we have a 30-60min network outage announced four months in advance. The better case is that it's an opportunity for us engineers to learn: by doing. (Doing in the sense of using IPv6 for those that haven't; and in the sense of watching/helping others use it for those that have been working with it for some time). Leslie. IETF Chair wrote: Dear Colleagues: How dark is the IPv6 Internet? Let's find out. During the IESG/IAOC Plenary at IETF 71, we are going to turn off IPv4 support on the IETF network for 30 to 60 minutes. We will encourage the audience to use the Internet and determine which services that they have come to take for granted remain available. If you are from a service provider, we encourage you to make your service a bright spot on the IPv6 Internet. To facilitate this experiment, a URL with instructions on how to get IPv6 running on Windows, Mac OS X, Linux, and so on. Some information will also be available for a 4-to-6 tunnel. We will ask everyone to list things that work and things that do not. The results will be part of the proceedings for the plenary session. We will make more information about the structuring of this activity over the next few weeks. Please do whatever you can to make ready ... Russ Housley IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
There are a few things I think people should keep in mind while discussing this: Russ has presented the IETF-particular case. If the solution lies in IETF process (i.e., update to RFC2026), that's fine. If the solution lies in adjusting RFC process, then we need to make sure there is agreement on how that impacts the whole RFC series (i.e., wider than IETF audience involved). For example -- shortening the appeal window (or going to a 2-stage process, as Ted noted) is an IETF process change.Determining that withdrawing a published RFC meets appeal-resolution requirements is an IETF process discussion. Changing the status of documents, or withdrawing them entirely, impacts the RFC series (RFC4844 and related). A wider discussion will be needed. (Note -- that wider discussion might be needed *anyway*, if there is belief that the ability to withdraw a published RFC is needed for other reasons.) Leslie. IETF Chair wrote: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. If we receive an appeal before the RFC is published, we can put a hold on the document, preventing pblication until the appeal has been studied. However, we have no way to pull an RFC back if it is published before the appeal arrives. As we all know, once an RFC is published, it cannot be changed. Thus, the RFCs form an archival series. If we find a bug in an RFC, we write a revised RFC that obsoletes the one that contains the error. So, what should we do if there is a successful appeal after the RFC is published? While we figure out what policy we want, I have asked the RFC Editor to not publish any IESG approved documents until their appeal timer has expired. I also challenged the RFC Editor to move things along so fast that this matters. I suspect they can. Which means that the whole IETF community needs to help the leadership figure out the appropriate policy before the rapid processing of Internet-Draft documents into RFCs becomes the norm. Russ -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A question about [Fwd: WG Review: Performance Metrics at Other Layers (pmol)]
Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and others. Milestones June 08 SIP Performance Metrics Draft to IESG Review for consideration as Proposed Standard Sept 08 PMOL Framework and Guidelines Draft to IESG Review for consideration as BCP ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Seeking a new IAB Executive Director
All, Due to other commitments Phil Roberts will not be able to continue his role as Executive Director. Therefore the IAB is currently looking to appoint a replacement. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. The Executive Director would be expected to be present in person at IETF meetings and IAB Retreats (typically one per year). The IAB has approximately 5 hours of teleconferences per month. We would like to receive your comments suggestions by April 2 2007 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. on behalf of the IAB, Leslie and Olaf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Seeking a new IAB Executive Director
All, Due to other commitments Phil Roberts will not be able to continue his role as Executive Director. Therefore the IAB is currently looking to appoint a replacement. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. The Executive Director would be expected to be present in person at IETF meetings and IAB Retreats (typically one per year). The IAB has approximately 5 hours of teleconferences per month. We would like to receive your comments suggestions by April 2 2007 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. on behalf of the IAB, Leslie and Olaf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Impending publication: draft-iab-raws-report-01.txt
The IAB is ready to ask the RFC-Editor to publish Report from the IAB Workshop on Routing and Addressing draft-iab-raws-report-01.txt as an Informational RFC. This document is a report from an invitational workshop convened by the IAB. As such, it represents the opinions of the attendees expressed at the time of the workshop. Please direct any comments to improve the clarity of the report to the IAB (iab@iab.org) by April 4, 2007. The document can be found at http://www.ietf.org/internet-drafts/draft-iab-raws-report-01.txt From the Abstract: This document reports the outcome of the Routing and Addressing Workshop which the Internet Architecture Board (IAB) held on October 18-19, 2006 in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
List of accepted nominations for IETF appointment to ISOC BoT
The procedure used by the Internet Architecture Board to select an individual to serve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process this year are: Joel Halpern Ted Hardie John Klensin Mike St. Johns Margaret Wasserman Bert Wijnen Comments on these candidates may be submitted to the IAB until April 1. The IAB will make a selection by April 13, 2007, and pass this selection to the Internet Engineering Steering Group for confirmation. Leslie, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Well, when the question (ION v. informational) came up within the IESG's discussion of the document, this is what I offered: On the ION v. RFC question -- I think this is *really* teetering on the edge! I've copied below the relevant section of draft-iab-rfc-editor-03. On the one hand, this document very clearly does not change the outcome of publish/don't publish decisions by the IESG (approvals). From that perspective, I think it describes a process and could reasonably be an ION if the IESG so desires. On the other hand, however, it does provide guidance and opinions about how proposed documents should be handled in individual or independent streams. Put another way: it's normative for the individual part of the IETF stream of RFCs. From that perspective, it should be published as an informational RFC as part of the suite of RFCs that provide the definition of the RFC series. In brief: if it's just IESG process within stated boundaries of IETF-stream documents, it can be an ION. If it affects the substance of what fits in that stream, I believe it fits under the umbrella of draft-iab-rfc-editor. Per the latter document, the IAB gets a say in determining community consensus when it comes to changing RFC series documents. The IAB isn't about to monitor IESG process pages (IONs); it'd have to be an RFC. So -- which is it? (I'm updating draft-iab-rfc-editor now, as it has finished its 4-weeks call for input; I'd like to know if I'm referencing an RFC-to-be or not :-) ). Leslie. P.S.: Again, copying the relevant bit from draft-iab-rfc-editor-03: From draft-iab-rfc-editor-03: 5.1. RFC Approval Processes Processes for approval of documents (or requirements) for each stream are defined by the community that defines the stream. The IAB is charged with the role of verifying that appropriate community input has been sought and that the changes are consistent with the RFC Series mission and this overall framework. The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams. 5.1.1. IETF Document Stream The IETF document stream includes IETF WG documents as well as individual submissions sponsored by an IESG area director. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards track or Best Current Practice (BCP) RFCs. Approval of documents in the IETF stream is defined by o the IETF standards process (RFC2026, [3], and its successors). Daigle Internet Architecture Board Expires July 15, 2007[Page 14] Internet-Draft draft-iab-rfc-editor-03January 2007 o the IESG process for sponsoring individual submissions (RFC , [9]). Changes to the approval process for this stream are made by updating the IETF standards process documents. John C Klensin wrote: --On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman [EMAIL PROTECTED] wrote: John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. Sam, I think we pretty much agree, and that is why my initial note wasn't much more aggressive. But it raises the issue that others have raised: if this meets the criteria for IETF documenting its procedures and, as you have described it above, informational, then why not publish it as an ION given that series was designed for just those sorts of things?Please take that as a question, not a position, but it is a very serious one. More generally, and independent of this particular document, it seems to me that, with IONs in the mix, publishing something that is informational about IESG procedures requires some explanation. Procedural BCPs do not, IONs do not, but informational documents of this variety have now become sort of an odd case. And, IMO, if something that could reasonably be published as an ION is proposed for publication as an Info RFC instead, then that ought to imply a decision that serious community discussion is in
Call for Nominations: IETF-Selected ISOC Trustee
The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the IAB's process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 15: Open nominations period. February 16: Close of nominations period. Publication of list of nominated candidates. IAB commences consideration of candidates. On or before April 13:IAB selection delivered to IESG for confirmation. On or before May 11: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB -- [EMAIL PROTECTED] Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: Eric Huizer 2004 - 2007 (*) Fred Baker 2005 - 2008 Patrik Faltstrom2006 - 2009 (*) Current term expires in 2007 Leslie Daigle, Chair, IAB ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nominees for IAOC seat to be appointed by the IAB
As described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333), the IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. Following the call for nominations which ran from November 17 through December 22, 2006, the IAB received four nominations of people who are willing to serve. They are: Joel Halpern Bob Hinden Jordi Palet Martinez Henk Uijterwaal The IAB expects to make a decision on or before January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). If any member of the community wishes to provide comments on some or all of these candidates, please send a note to [EMAIL PROTECTED] in the next 2 weeks (i.e., by January 25). Leslie Daigle, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Timeline for the IAB's annual ISOC Board of Trustee Appointment Process
The IAB is announcing its timeline for the appointment of a member of the Internet Society (ISOC) Board of Trustees, as described in BCP 77 (RFC 3677). The IAB selects one person for a three-year ISOC BoT term every year. This year, the IAB will select one person for a term ending in spring 2010. The IAB will issue a call for nominations on the ietf-announce@ietf.org list on January 15 with an open nomination period running until February 16. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (February 16). The IAB expects to announce its selection on April 13. The IESG will confirm the candidate and he or she will begin serving as the new board of trustee member in June. Leslie Daigle, Chair, IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
FINAL call for nominations: IAOC position selected by the IAB
The IAB is making a call for nominations for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The incumbent is Lucy Lynch, who was selected by the IAB for an initial two year term expiring in spring 2007. Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. The candidates will also be expected to exercise all the duties of an IAOC member, including being prepared to undertake any associated responsibilities. These include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. The candidates must be able to undertake full participation in all Committee meetings and Committee activities. The IAB-selected member of the IAOC does not directly represent the IAB. The IAB and IESG selected members are accountable directly to the IETF community. Candidates do not need to be current members of the IAB or IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to Phil Roberts, Executive Director of the IAB at [EMAIL PROTECTED]. The IAB will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to make a decision on or before January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Second call for nominations: IAOC position selected by the IAB
The IAB is making a call for nominations for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The incumbent is Lucy Lynch, who was selected by the IAB for an initial two year term expiring in spring 2007. Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. The candidates will also be expected to exercise all the duties of an IAOC member, including being prepared to undertake any associated responsibilities. These include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. The candidates must be able to undertake full participation in all Committee meetings and Committee activities. The IAB-selected member of the IAOC does not directly represent the IAB. The IAB and IESG selected members are accountable directly to the IETF community. Candidates do not need to be current members of the IAB or IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to Phil Roberts, Executive Director of the IAB at [EMAIL PROTECTED]. The IAB will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to make a decision on or before January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Call for nominations: IAOC position selected by the IAB
The IAB is making a call for nominations for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The incumbent is Lucy Lynch, who was selected by the IAB for an initial two year term expiring in spring 2007. Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. The candidates will also be expected to exercise all the duties of an IAOC member, including being prepared to undertake any associated responsibilities. These include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. The candidates must be able to undertake full participation in all Committee meetings and Committee activities. The IAB-selected member of the IAOC does not directly represent the IAB. The IAB and IESG selected members are accountable directly to the IETF community. Candidates do not need to be current members of the IAB or IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to Phil Roberts, Executive Director of the IAB at [EMAIL PROTECTED]. The IAB will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to make a decision on or before January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Announcement of timeline for IAOC position selected by the IAB
The IAB is announcing its timeline for the appointment of a member of the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and in BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The IAB will issue a call for nominations on the ietf-announce@ietf.org list on November 17 with an open nomination period running until December 22. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to announce its selection on January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, Chair, IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Impending publication: draft-iab-link-encaps-02.txt
The IAB is ready to ask the RFC-Editor to publish Multiple Encapsulation Methods Considered Harmful draft-iab-link-encaps-02.txt as an Informational RFC. While typically a link layer protocol supports only a single Internet Protocol (IP) encapsulation method, this is not always the case. Recently new link types have been defined that support multiple encapsulation methods. This document describes architectural and operational issues arising from use of multiple ways of encapsulating IP packets on the same link. Multiple encapsulation methods are not, themselves, new -- previous considerations of the approach are considered, as well as a review of potential issues related to the current proposals. The IAB solicits comments by September 27, 2006. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-link-encaps-02.txt From the Abstract: This document describes architectural and operational issues that arise from link layer protocols supporting multiple Internet Protocol encapsulation methods. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Now there seems to be lack of communicaiton here...
I think this has already been said in this thread, but just to be very clear on one point: Andrew's message does read as if the IAB IESG were somehow consulted. They were not. Brian I were on the cc list of one complaint; we certainly agreed the situation needed addressing. No doubt that motivated Andrew's text. I will note, however, that the ultimate decision of whether, and certainly the choice of *how*, was up to Lynn and/or Andrew by a means of their own devising. Leslie. Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ 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: [IAOC] Re: RFC Editor RFP Review Request
Note that I never said that the IAB was not part of the IETF family/universe/collection. The important thing is that the IAB is independent in its decision making, and not subject to the IESG's whims or strictly bound by the IETF's input, which appeared to be the key elements in your concerns of IETF ownership. draft-iab-rfc-editor-01 (now in the repository) lays out a framework for the IAB to ensure there is a (broader-than-IETF) community-defined RFC series, with community input and feedback. So -- it's a proposal for community-driven RFC Series not under IETF (IESG) control. Leslie. Joe Touch wrote: Leslie Daigle wrote: ... [*] This is perhaps a reasonable time to reiterate that the IAB is, in fact, a separate entity from the IETF organization. There are many who believe that all RFCs are Internet standards documents, thus the current concern with adding IESG non-review statements to independent submission (which I reiterate - I do not recognize their right to do so). There are many who also believe that the IAB, by virtue of being appointed by exactly the same body as the IESG, is part of the IETF. You can point to your org chart all you want; sauce for the goose is sauce for the gander. Either the actual differences matter, or we're working off of public perception. Perhaps it's time that the IETF demand that all IAB statements and documents begin with an IETF separate entity disclaimer as well? Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IAOC] Re: RFC Editor RFP Review Request
Actually: . since the existence of the IASA (last year), the ISOC BoT has been asked to support the RFC Editor as part of what IASA supports -- IETF *and* IAB (and IRTF). . as part of the initial proposal of 2007 budget for IASA, to the ISOC BoT, on July 1, 2006, it was proposed this model continue. I.e., ISOC is asked to support IASA. IASA supports the IAB as well as the IETF.[*] The IAB asks for support for the RFC Editor. The IAB has been working through this year to formalize a proposed framework for answering the questions of who controls what under which circumstances. It started with the proposed RFC Editor charter in March. It is now a 14 page Internet-Draft (submitted to the repository yesterday; should be out RSN: draft-iab-rfc-editor-01 is the current version). [*] This is perhaps a reasonable time to reiterate that the IAB is, in fact, a separate entity from the IETF organization. Leslie. Ted Hardie wrote: At 7:25 PM -0400 7/25/06, John C Klensin wrote: And the IETF/IASA can issue an RFP for IETF publications and publishing any time it likes, specifying whatever conditions it likes. _That_ is perfectly normal. It can even try to specify what other activities an entity that responds to the RFP may or may not engage in. That would likely be stupid, since it would probably reduce the number of bidders and increase costs, but nothing prevents the IETF from doing so. What it cannot do is to assume it has the right to impose those requirements on the RFC Editor and that, if the RFC Editor doesn't agree, the IETF's remedies extend beyond taking its publication business elsewhere. Absent figuring out who or what the term RFC Editor belongs to (I don't know whether it is ISI, but is certainly is not the IETF unless I get to transfer your name after buying you lunch), the RFP should be titled something more like ... for services currently performed by the RFC Editor John, Leaving aside all of the naming issues, I believe the point that is being missed is that ISOC, through this IASA process, intends to fund two things: an IETF stream of documents and an independent stream. It can put conditions on the independent stream solely because it will pay for the publication of that stream. As you point out, that has nothing to do with any publication work done for anyone else by the respondents; it simply means that for the independent stream paid for by ISOC, a particular set of processes are being put forward to ensure that they relate to the IETF stream (or don't relate to it) in particular ways. I would appreciate it if we kept that point, and what the particular set of processes should be, separate from the naming issue. The worms in one can need not interbreed with the worms in the other. thanks, Ted Hardie I continue to hope and believe that, if the RFP and award process is obviously fair, in the best interests of the Internet community ISI will consent to the release of any rights they might have to the RFC Editor terminology and materials to whatever entity the IASA decides to designate. But at least some of us believe that making the approval process or content of RFCs that do not arise from IETF processes subsidiary to the IESG would not be in the best interests of the Internet community. Were the RFP to go out with such a requirement, and were USC to agree with that conclusion about the best interests of the community, things could get rather strange. You might also argue that even if ISOC gets some say in how the RFC-Editor function is performed as long as it is funding it, and has the right to stop funding it, ISOC (and by extension, the IETF) doesn't have the right to hire someone else to be RFC-Editor. That is correct. If I understand correctly, this is the question you don't want to put in the critical path of this RFP. Unfortunately, I think this is something that must be resolved before the process goes too far. I'd hate to see people's decisions affected by concerns over what might happen if ISI doesn't get the contract. So would I. For just this reason, I have repeatedly tried to suggest that the RFP should specify a series of functions to be performed, rather than the name to be given to the entity that performs it, but those suggestions haven't gone anywhere and the process has probably already gone too far. Were that change made, I would still argue that there should be an independent submission model and that ISOC (IASA, IETF) still should not assert IESG control over it and should not permit IESG to insert required text into independent submissions that was not true and/or exceeded the IESG's knowledge and quality of review. But that discussion at least would not get tied up with the concept of the RFC Editor and its role. john ___
Re: Comments on draft-iab-rfc-editor: IETF control
Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: there is no dispute (afaict) that the RFC Editor series started before the IETF, or that it has had a broader mandate than IETF standards. The IAB document is consistent with the operational facts that have governed operation at least in the years since ISOC has been funding the RFC Editor effort, and offers a way forward to ensure a continued funded independent series which respects that history. I understand you are disagreeing with that proposal; I am not hearing a viable alternative proposal that respects the governing operational reality. I believe pursuing this line of argument overlooks the intervening history (e.g., *all* RFCs since approx 2000 bear ISOC copyright; the RFC Editor work was done under contract as work for hire). Worse, I believe pursuing this line of argument can only lead to a future where the RFC series is split (IETF documents and not), and the RFC Editor function expires for lack of financial support. (I haven't heard your proposal for how that doesn't happen?). In short -- the draft is a best effort proposal for establishing a viable future that respects the history of this function and gives it a future. *Please* contribute to making this proposal better, don't just say it ain't so! BTW, the discussion of that independent submission stream is at [EMAIL PROTECTED] . Leslie. Michael StJohns wrote: Brian - In absolute seriousness, I could publish an ID/RFC or other document that says that I'm the king of the Internet - doesn't make it so. These are the facts as I understand them. 1) The RFC Series has always been at ISI, originally under Jon Postel the RFC Editor, but more recently under Bob Braden's direction. 2) The RFC Series was first begun in 1969 and was for the most part a commentary on the ARPANet experiment until the late 1970's. 3) The RFC editor function was paid for in its entirety by the US Government from 1969 until sometime in 1997-98. 4) The IETF didn't begin until 1986. 5) The first lists of IAB standards didn't appear until 1988 (RFC1083) and that document made it clear that standards were only a part of what the RFC Editor did. Note that at that time the author of 1083 was listed as Defense Advanced Research Projects Agency, Internet Activities Board It wasn't for another few years (approx 1991 I believe) that the split of standards into Draft/Proposed/Standard began to be reflected in the successor documents to 1083 6) The RFC Editor has been either a defacto or dejure member of the IAB going back pretty much to its inception (I don't know exactly how far) so saying the IAB was responsible for the RFC series was correct, but to more properly state it The IAB [in the person of the RFC editor] is responsible for editorial management... brackets mine. Jon was a polite guy and didn't like a lot of disharmony in his life - I'm not surprised the language stood as it did - he didn't see its as a distinction with a difference. 7) The standards RFC STD 1 describes the standardization process. It is not and has never been inclusive of the other work done by the RFC Editor. 8) I've seen no mention of the transfer of the term of art RFC Editor or RFC Series to either the IAB, IETF, or ISOC. E.g. the mere fact the ISOC pays for the publication of RFCs does not necessarily give them ownership of that term or the series itself. Conclusions: 1) The RFC Editor is not just the Internet Standards process. 2) The RFC Series, while it is currently the archival series for the Internet Standards, is broader than just that process. 3) The Internet Standards series could be published by another channel. 4) The terms RFC Editor and the right to publish the RFC series probably vest with ISI absent of any other agreement between ISI and some other entity. These facts and conclusions lead me to the conclusion that the RFC Editor is currently the publisher of Internet Standards, the publisher of Internet Standards is not necessarily the RFC Editor. The IETF/IABs interest in the RFC Editor must be limited to those specific roles we ask him to take on for us and must not bleed over into to trying to control other aspects of the RFC Editor organization. With respect to your question of how to make the RFC Editor answerable to the community - I wouldn't. I'd make the publisher of Internet Standards answerable for the publication of Internet standards and not interfere in the other work they're doing. E.g. if you don't like what the RFC editor is doing with your standards, move the standards series someplace else. If you do move it someplace else, don't expect to constrain what else they do. If you want that series to be the RFC series - ask ISI nicely for the transfer of rights to the IAOC. Once that happens I'll shut up about the need to keep in mind that the RFC Editor and the publisher of
Re: Comments on draft-iab-rfc-editor: IETF control
Mike, Michael StJohns wrote: At 03:04 PM 6/9/2006, Leslie Daigle wrote: Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: I love it when discussions start out with throw away the facts. That's a mischaracterization of what I said, and I'll accept an apology. The RFC Editor through agreement with the IAB and with funding from the ISOC publishes the Internet Standards series under the banner of the RFC Series. No, ISI publishes (all) RFCs under contract from ISOC. Fact. rest deleted Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
I agree that the principle of avoiding interference is a general one that could be captured in this document. And I think this document had better be consistent in its application of principles. I will observe that as the documents are currently structured, the definitions of the individual streams discuss the details of handling those (inter)dependencies. Therefore, I believe your last sentence belongs as a comment on [EMAIL PROTECTED] and specifically on the document draft-klensin-rfc-independent . If this document is to capture *all* the specificallys of document stream interdependence, we will also have to capture the expectation that the IETF stream will not interfere with the IAB stream, and so on. I don't think that's effectively achievable or even maintainable in this document. Leslie. Brian E Carpenter wrote: Although I'm an IAB member, I'd rather make my one comment on this draft in public. I think it misses one point that should be mentioned. The easiest way to explain it is to suggest new text: 4.4. Avoiding interference between publication streams Although diversity of views and alternative solutions are common and will commonly be published, it would be highly undesirable for documents published in the different streams to interfere actively with each other, for example by specifying incompatible extensions to the same protocol or alternative uses for the same parameter value. For this reason, the procedures adopted for the four streams will include appropriate checks and balances to avoid such interference. Specifically, this will include a procedure (currently documented in [RFC3932]) to avoid Independent Submissions actively interfering with IETF Documents. Brian ___ 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
Open mailing list for the discussion of Independent RFC Submissions Process
As part its role in supporting the RFC Editor function, the Internet Architecture Board (IAB) has created a public mailing list for the discussion of the RFC Independent Submissions process. The purpose of this discussion is to achieve consensus, in the coming weeks, on a process for fair and appropriate approval of independent submissions to the RFC series. These are separate from IETF, IAB or IRTF approved submissions. Individuals familiar with the RFC series and working in the Internet research and engineering community are invited to join this mailing list and participate. independentatietf.org https://www1.ietf.org/mailman/listinfo/independent There is an initial draft proposal, available at http://www.ietf.org/internet-drafts/draft-klensin-rfc-independent-02.txt Leslie Daigle, Chair, IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Comments on draft-iab-rfc-editor: IETF control
Indeed -- the potential for leaving the RFC Editor split or hanging in space is one of the driving reasons behind elaborating the existing IAB charter text and creating this document. The key elements are: . the RFC Editor has been under the auspices of the IAB for some time (at least since the IAB Charter, RFC2850; Ran Atkinson dated it back to 1992). . the IAB is supported by IASA, and therefore the whole of the RFC Editor should be supported by IASA . draft-iab-rfc-editor describes how the IAB would shepherd the definition of the independent submissions process, which is about as light a hand as is manageable while keeping the whole consistent. On that latter point -- [EMAIL PROTECTED], the list for discussing proposals for independent submissions, has been created: https://www1.ietf.org/mailman/listinfo/independent And, to date, the one proposal draft I have seen is draft-klensin-rfc-independent-02.txt Leslie. John C Klensin wrote: --On Wednesday, 31 May, 2006 05:02 +1000 Geoff Huston [EMAIL PROTECTED] wrote: This isn't really a chartering issue, IMHO. I must strongly disagree here Brian - irrespective of any details of implementation, the level of independence and discretion granted to the RFC Editor to edit and publish documents that are not the outcome of the IETF's peer review process is, I believe, a central matter in any version of an RFC Editor Charter. While I agree with Geoff, this then makes the question of how that charter should be reviewed and approved a critical issue. I'm comfortable having the IAB do that, as long as it is done in collaboration with the current RFC Editor staff rather than as an independent decision made in an adversarial climate (I don't read a requirement for, or an assumption of, an adversarial climate into the draft or Leslie's note) and as long as the IAB understands that it is responsible to a community that extends well beyond the IETF and that may have an affirmative interest in views that dissent from IETF (or IESG) decisions and positions. For those who believe that the IETF --presumably as represented by the IESG-- should have controlling authority over what the RFC Editor does across the board, I'd recommend a thought experiment: As I understand it, none of the support for the RFC Editor in recent years (or ever) has come from IETF meeting fees. The support comes from ISOC and the largest fraction of that ISOC support is earmarked corporate contributions. Now, with the understanding that I'm neither predicting nor advocating this course of action, suppose those companies were convinced that an independent RFC Editor --independent of IETF control -- was important and that they would prefer to fund that and let the IETF take care of itself (or, more likely, that they would fund the two separately but control the ratios). It seems to me that would leave us in exactly the position others have suggested: the IAB could designate the technical publisher for IETF documents, but that might be an entity completely separate from the RFC Editor and the RFC name and series might stay with the entity designated by ISOC or the relevant sponsors. Now, it seems to me that it is in everyone's interest to avoid getting anywhere near a state in which a scenario like that started being seriously discussed. Doing so implies, I think, a minimum of hubris, a minimum of assertions about IETF authority over non-IETF documents, and a maximum of IAB working together with the RFC Editor to find a right way forward, rather than assuming that one body can dictate to the other. That line of reasoning, and the consequences of the thought experiment, leads to another conclusion which I would not have guessed at a few weeks ago: the IAOC has limited or no authority to compete an RFC Editor contract to cover tasks other than those directly related to the IETF except on the advice and consent of the ISOC BoT or some other ISOC entity (in either case with the ISOC entity acting as representative of the relevant organizational members). I believe that a well-designed RFI process is, at worst, harmless and might produce information that would be beneficial to all parties. But the assumption that the IAOC can then award a contract that covers non-IETF publications may not be reasonable. What a strange world our reasoning and desires for more control get us into. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Sam, Some high-level responses, and I'm sure we'll hear other input: 1/ I think you're overlooking something in IETF pays for RFC Editor; RFC Editor has been paid by ISOC for years, and *that* largely comes out of contributions from corporations. We actually have no data beyond the fact that they support the RFC Editor as currently constituted (i.e., including independent submissions). We've already heard (in IETF discussion in March) input that no in fact the IETF does not get to define the *in*dependent submission process; one purpose of the planned discussion is to ensure that the process is not at odds with the IETF's standards needs, but that is very different than having the IETF define it, as you describe. 2/ Termination of any contract is always going to be based on terms in said contract. I assume ISOC BoT wouldn't approve something that leaves them with dangerous exposure; that's what they do. This document is aiming to capture the principle of the IAB's responsibility; the counter example is not right, either (the IASA giving the IAB/IETF the news that there is a new RFC Editor in town). 3/ Re. approval of ISOC BoT/IASA for creation of new streams: we need to be careful with terminology. The IASA exists to implement adminstrative support to meet the needs of the IETF IAB IRTFs needs. Leslie. Sam Hartman wrote: I finished reading the RFC editor document and have one major concern. Ultimately, the rfc-editor function needs to be accountable to the IETF community because we're the ones paying for it. In particular I believe that the IETF should be able to pass a BCP placing requirements on an rfc-editor stream. We've done this with RFC 3932 for example, and I think that was a good thing. In effect, community consensus within the IETF should trump anything else. Now, we need to be careful about how to use that consensus. Several RFC streams serve communities broader than the IETF. Unless we have good reason to do so, we should not step on those communities by overriding their requirements. I also have specific concerns about how this document interacts with the IAOC and IASA. 1) The document gives the IAB the authority to terminate the rfc-editor contract. Depending on when we do that, there may be significant budget impacts and it may not be consistent with ISOC's carrying out its financial responsibilities to terminate the rfc-editor contract at an arbitrary point in time. 2) The document allows the IAB to create new streams of rfcs on its own authority. It seems that we need ISOC and IAOC approval at least on the budget question to do so. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Howdy, I think though that the community ultimately needs to have the power to take back anything it has given. Basically, I think it is critical that ultimately everything within the greater IETF context be accountable to the IETF community. That is true of the IESG, the IAB and everything they do. I don't think this document represents that. It is, at its heart, an -00 :-) Let's work on trying to fix the text before assuming the whole structure is wrong. Let's set aside *which* community for a moment (IETF community or something larger) and work on making sure the document is clear where the IAB makes decisions versus where it facilitates the detection of and action upon consensus. Can you propose some text improvements? Leslie. Sam Hartman wrote: Leslie == Leslie Daigle [EMAIL PROTECTED] writes: Leslie Sam, Leslie Some high-level responses, and I'm sure we'll hear other Leslie input: Leslie 1/ I think you're overlooking something in IETF pays for Leslie RFC Editor; RFC Editor has been paid by ISOC for years, Leslie and *that* largely comes out of contributions from Leslie corporations. We actually have no data beyond the fact Leslie that they support the RFC Editor as currently constituted Leslie (i.e., including independent submissions). Leslie We've already heard (in IETF discussion in March) input Leslie that no in fact the IETF does not get to define the Leslie *in*dependent submission process; one purpose of the Leslie planned discussion is to ensure that the process is not at Leslie odds with the IETF's standards needs, but that is very Leslie different than having the IETF define it, as you describe. OK. I was not paying that much attention in March,and if I'm too late, I certainly have no problem with the community choosing to allow a broader group to control the independent submission track, or to seed that to the IAB. I think though that the community ultimately needs to have the power to take back anything it has given. Basically, I think it is critical that ultimately everything within the greater IETF context be accountable to the IETF community. That is true of the IESG, the IAB and everything they do. I don't think this document represents that. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Seeking... IAB Executive Director
Thanks to all those who considered volunteering for this position! And, I'm pleased to announce that Phil Roberts will be taking up the post. Thanks, Leslie. Leslie Daigle wrote: All, The IAB is currently looking to appoint an Executive Director. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. We would like to receive your comments suggestions by April 14th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. Leslie Daigle, for The IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Impending publication: draft-iab-idn-nextsteps-05
The IAB is ready to ask the RFC-Editor to publish Review and Recommendations for Internationalized Domain Names (IDN) draft-iab-idn-nextsteps-05 as an Informational RFC. The chief purpose of this document is to provide a survey of issues that have been raised with regards to the deployment of IDNs and propose potential avenues for exploring and/or resolving them. The IAB solicits comments by May 17, 2006. Please send comments to the IAB (iab@iab.org) and authors (cc'ed here), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-idn-nextsteps-05.txt From the Abstract: This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and those for use of those names for use in the DNS. It recommends that IETF should update the IDN related RFCs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the IDNA standard and its supporting tables, based on experience gained since those standards were completed. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Seeking... IAB Executive Director
Hmm... judging from some of the responses we've had, there's an important clarification to make here: [I wrote:] - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. Every IAB member (ex officio or not) is expected to have enough time to read and keep up with the IAB mailing list discussions. The IAB executive director, although non-voting, does participate in IAB technical discussions. While the executive director does have the clerical work to track, they're less likely to get stuck with IAB document editing tasks, so on balance the time committment and overall participation is probably about the same as any other actively-involved IAB member. Hope that helps, Leslie. Leslie Daigle wrote: All, The IAB is currently looking to appoint an Executive Director. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. We would like to receive your comments suggestions by April 14th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. Leslie Daigle, for The IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Seeking... IAB Executive Director
All, The IAB is currently looking to appoint an Executive Director. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. We would like to receive your comments suggestions by April 14th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. Leslie Daigle, for The IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
John, everyone, I think it's fair to say that the IAB has heard the concern at this point -- about the net neutrality issue, and the desire to see some concrete IAB action. I've also seen a fair bit of discussion about what an appropriate stance *is*, and whether or how to express it as a useful and usable (IAB) action. I'm not sure that timid is the right word -- in at least some instances, considered would be better. Which means there could (should?) be some time delay between heard the concern and that concrete IAB action. Leslie. John C Klensin wrote: Tony, I agree completely and believe the IAB has, of late, been altogether too timid in this area. I think you know all of what I'm about to say, but your note is, IMO, easily misread, so an additional observation about 4084 and its potential relatives: In this sphere, a document that says XYZ is evil is essential worthless. The companies considering XYZ will almost always say hmm, there is a tradeoff here. One possibility is that I can increase profitability. The other is that I can pay attention to that group of geeks who are living in some other reality. Guess which wins, almost every time? There are two strategies that make more sense and have more chance of success. One is precisely what 4084 attempted to do: lay out categories and boundaries that, if adopted, make better information available to potential users/customers and provide a foundation for regulation about what must be accurately disclosed (as compared to what is required). That said, I've been quite disappointed with the results of 4084: from the comments and input I got before we did the work, I was optimistic that we would see at least some ISPs, and maybe even some regulators, pick the concepts and terminology up. To put it mildly, it hasn't happened. The other approach, with thanks to Dave Clark for pointing it out to me a few years ago, is to carefully write a neutral and balanced document whose theme is of course the Internet architecture permits you do this, but, if you do, it will have the following good and bad consequences which you should understand in making your decisions. Either approach requires serious work and people on the IAB who are interested, willing, and have the skills to do it. I can't speak for the current IAB at all but, if the sort of output Tony and I are talking about is wanted, then people need to tell the Nomcom(s) that the ability and willingness to generate it should be an important candidate selection criterion. john --On Thursday, March 23, 2006 20:20 -0600 Tony Hain [EMAIL PROTECTED] wrote: I didn't make it to the mic fast enough at the end, but Brian's comment about the proposal to outlaw diffserv actually gets to the heart of why the IAB needs to take specific stands and make public comments. Telling the telco's they are evil is not the point. General statements of principle or observations of past behavior like 'walled gardens are not conducive to open application innovation and frequently result in additional layering complexity to traverse the walls', or 'allowing people to elect going to the head of the line is what the QoS toolset is about'. I am not sure what the right language is but there is probably something the IAB could say about misusing the tools to effectively set up an extortion/protection racket being a possible side effect that regulators might want to consider, but that cutting off the tools outright would actually hamper some potential new service and application development. The point is that if the IAB stands back without making any statement there will be no guidance about the impacts of various business/deployment models. Something along the lines of 4084 that takes no particular position of right or wrong, but identifies the consequences of potential actions might help to stabilize the public debate. After all even open application development might be considered wrong by some, but when coupled with the observation that it happens anyway with more complexity and cost might get all the fundamental issues on the table. Tony ___ 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
Issue with current IAB mid-term replacement
An issue has been raised about how to interpret RFC 3777 in the case of the replacement for Pekka Nikander on the IAB. Specifically, the duration for the replacement's appointment is ambiguous, as different interpretations are possible (have been made) as to whether the point of interest is when the mid-term vacancy occured (which was before IETF65) or when the replacement is named (which will obviously be after IETF65). The IAB takes no position on what the answer *should* be, but in the interest of giving the NomCom clear and direct guidance, we have reiterated our request to find a replacement for the remainder of Pekka's term -- to March of 2007. This seems the most straightforward path given competing interpretations of RFC 3777. This seems to be an instance of testing a corner case in the process RFC. We suggest RFC 3777 should be amended with due speed to prevent similar confusion in the future. Leslie. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: STRAW PROPOSAL RFC Editor charter
Carl, Carl Malamud wrote: Carl -- did you get the other message (the one with the timeline)? Yes, I did. Good - and I'd like to hear your comments on *that*. I'm curious about: 1. the opinion from the RFC-Editor about this, in particular the charter. I assume you're asking this generally -- I would not presume to speak for the RFC Editor on that question. 2. what the IAB/IAOC is thinking ... this could be a sole source reassignment or a simple renewal. It is *not* news that there would be an RFP for this role in 2006 -- this is an attempt to get the plan out to the community for discussion in advance of execution. As Brian observed, the IAOC has understood the community to prefer solicitation for multiple bidders on any given function. That doesn't in any way preclude the possibility of the appointment going to our current RFC Editor crew, but it does mean that the IETF gets an opportunity to review the task, its expectations/requirements of it, and the relationship (contract) to carry out the work. Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
Suggestion? Are they independent submissions, or RFC Editor contributions? They are clearly not currently IAB, IETF or IRTF docs... Leslie. Scott Bradner wrote: The other publication tracks in the above is meant to be for -- IAB, IRTF, independent submissions, whatever comes next. and 1 april RFCs? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Impending publication: draft-iab-liaison-guidelines-02.txt
The IAB is ready to ask the RFC-Editor to publish Guidelines for Acting as an IETF Liaison to Another Organization draft-iab-liaison-guidelines-02.txt as an Informational RFC. The chief purpose of this document is to provide practical guidelines to IETF liaison managers and persons considering undertaking such a role. The IAB solicits comments by April 14, 2006. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-liaison-guidelines-02.txt From the Abstract: Whenever IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052 [RFC4052]. This document gives guidelines on expectations, tasks, responsibilities and mandate of the liaison managers. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC Editor and 2006 timeline
The IAB and IAOC have put together the following proposed plan for clarifying the RFC Editor function and running through a contract review process this year. The key pieces of this proposed process are: . getting agreement on a basic RFC Editor charter . completing TechSpec to describe requirements for IETF technical specification publication . developing analogous components for independent submissions, IRTF documents, etc. (Not all yet on the timeline). Comments welcome. Draft timeline/division of labour = Responsible parties in [], where IASA is IAD or IAOC as appropriate. Mar 14 2006 [IAB] Draft RFC Editor charter out for public comment. Mar 20 2006 [TechSpec/IETF] TechSpec meeting Mar 20 2006 [IAB/IETF] Discuss RFC Editor charter Apr 15 2006 [TechSpec] Target reasonable consensus document. Apr 15 2006 [IETF] Start of 4 week last call of TechSpec document Apr 15 2006 [IAB] Revised RFC Editor charter. May 7 2006[IASA] Request for Vendor Expressions of Interest May 15 2006 Close of last call of TechSpec document Jun 1 2006[IASA] Vendor Expressions of Interest Due Jul 15 2006[IASA] RFP(s) Issued Sep 1 2006[IASA] Bids Due Sep 2006[IASA] Contract Negotiation Sep 25 2006[IAB] IAB review Oct 1 2006[IASA] Contract(s) Awarded Oct – Dec[IASA] Transition Period Jan 1 2007 Contract term begins Leslie Daigle. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
STRAW PROPOSAL RFC Editor charter
Following the note just sent about the proposed timeline for reviewing the RFC Editor contract this year, here is the STRAW proposal RFC Editor charter proposed by the IAB. It is a modest extension of the RFC Editor paragraph as found in RFC 2850 (the IAB Charter). The purpose of this straw proposal is to inform discussions scheduled for the GENAREA meeting at IETF65 in Dallas. After the Dallas meeting, the IAB will provide a more formal charter proposal. STRAW RFC Editor Charter The RFC Editor executes editorial management for the publication of the Request for Comment (RFC) document series, which is the permanent document repository of the IETF community. The RFC series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. It is the responsibility of the IAB to approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. Policies, including those for defining publication tracks and their requirements, intellectual property rights, as well as editorial review and approval processes, must be defined in IETF community consensus documents before being put to the IAB for approval. Leslie Daigle. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
I want to speak to one facet of comment that I believe is going to be a common thread: [Ran Atkinson wrote:] Similarly, it is a bug that the IETF process would govern the publication of non-IETF documents. The IETF process properly should govern how IETF generated documents should be handled for publication. However, the IETF processes ought not govern how IRTF, IAB, or other non-IETF documents are handled by the RFC Editor. TechSpec is working on the IETF requirements, specifically. The other publication tracks in the above is meant to be for -- IAB, IRTF, independent submissions, whatever comes next. When the current IAB/IESG organisational structure was setup, it was a deliberate choice to have the RFC Editor under the IAB and not under the IESG -- because the RFC Editor's scope was (and is) much larger than the IETF or the IESG's scope. Requiring that all policies have to go through the IETF processes (which many IETF people consider badly wedged) for approval is a major and undesirable change, IMHO. The goal is to have a public means for defining, adjusting and agreeing to the requirements of those tracks.Better formulations for that welcomed! Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
STRAW PROPOSAL RFC Editor charter
Following the note just sent about the proposed timeline for reviewing the RFC Editor contract this year, here is the STRAW proposal RFC Editor charter proposed by the IAB. It is a modest extension of the RFC Editor paragraph as found in RFC 2850 (the IAB Charter). The purpose of this straw proposal is to inform discussions scheduled for the GENAREA meeting at IETF65 in Dallas. After the Dallas meeting, the IAB will provide a more formal charter proposal. STRAW RFC Editor Charter The RFC Editor executes editorial management for the publication of the Request for Comment (RFC) document series, which is the permanent document repository of the IETF community. The RFC series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. It is the responsibility of the IAB to approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. Policies, including those for defining publication tracks and their requirements, intellectual property rights, as well as editorial review and approval processes, must be defined in IETF community consensus documents before being put to the IAB for approval. Leslie Daigle. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IAB mid-term vacancy
Two weeks ago, Pekka Nikander announced to us his resignation from the IAB. I'd like to thank Pekka for his time and contributions to the IAB, and wish him all the best in pursuing his professional goals! The IAB has decided to fill this mid-term vacancy, and has informed the NomCom. Leslie, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
List of accepted nominations for IETF appointment to ISOC BoT
The procedure used by the Internet Architecture Board to select an individual to serve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process this year are: Margaret Wasserman Patrik Faltstrom John Klensin Avri Doria Jordi Palet Martinez Comments on these candidates may be submitted to the IAB until April 1. The IAB will make a selection by April 5, 2006, and pass this selection to the Internet Engineering Steering Group for confirmation. Leslie, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
FYI -- IAB statement on IANA RFI
As you may have seen, the Department of Commerce has recently published a Request for Interest (RFI), for the whole IANA function: http://www.fbo.gov/spg/DOC/OS/OAM/Reference%2DNumber%2DDOCNTIARFI0001/SynopsisR.html While the RFI was not a surprise, the IETF was not consulted in any way about the technical parameter assignment portion of the IANA work. As noted in the message we just sent in reply to this RFI, this gives us some concern in terms of potential impact for IETF work. http://www.iab.org/documents/correspondence/IANA-2006/IAB-RFI-Input.pdf The IAB will be working through this year with the IAOC to ensure the IETF continues to have a suitable technical parameter assignment function. Leslie, for the IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAB Response to the Appeal from Julian Mehnle
that this paragraph explicitly permits the publication of work that conflicts with existing IETF standards work, provided that it bears an appropriate disclaimer. In this case, the IESG provided a substantial disclaimer. Without determining whether or not this experimental document actually conflicts, we conclude that the disclaimer added by the IESG would in any event be sufficient to allow the publication of this document as Experimental. 4. IAB Conclusion On the basis of the available record and the IESG's response, the IAB concludes that the IESG gave due consideration to the technical issues raised by Mr. Mehnle and reached a decision according to the process specified by RFC 2026. We therefore conclude that the appeal should be denied and the original IESG decision upheld. Note: IAB voting member Bernard Aboba recused himself from the discussion and decision of this appeal. Leslie Daigle, for the IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Third Call for Nominations: IETF-Selected ISOC Trustee
This is a Third (and final) Call for Nominations The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the IAB's process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 19: Open nominations period. February 22: Close of nominations period. Publication of list of nominated candidates. IAB commences consideration of candidates. On or before April 5: IAB selection delivered to IESG for confirmation. On or before May 3: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB -- [EMAIL PROTECTED] Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: Margaret Wasserman 2003 - 2006 (*) Eric Huizer 2004 - 2007 Fred Baker 2005 - 2008 (*) Current term expires in 2006 Leslie Daigle, Chair, IAB ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Request to the IAB for clarifiction of its Jan 31 IAB Response to Appeal from Jefsey Morfin
Harald, Indeed, the IAB response concludes that the IESG has not given sufficient justification for its decision in Mr. Morfin's appeal, and that decision has been annulled. The IAB's role here is one of review (in the appeal), not directing the actions of IETF process. If you require further direction, I refer you to the IESG. Leslie. Harald Tveit Alvestrand wrote: Hello, as the person responsible for the mailing list in question on Jefsey Morfin's appeal that the IAB responded to on January 31, I have a question for clarification, which has an immediate effect on what this maintainer will do while this stuff is being processed. Quoting from the IAB response, and trying to cover only the important facts: The IAB interpreted this appeal to be as follows: The appeal concerns whether the IESG, in upholding the suspension of Mr. Morfin's posting privileges to the ietf-languages mailing list, made an incorrect decision. .we find there is no specific mailing list management process RFC that applies. While we find that neither RFC 3683 nor RFC 3934 directly apply in this case, the IAB understands that the IETF must be able to act in the face of ambiguity in the rules. Indeed, it would be a terrible outcome if we found the IESG's decision would have been reasonable if neither RFC 3683 nor RFC 3934 existed, but now unreasonable since the documents do exist but don't apply. Responsible parties must be able to take action even if there is ambiguity or lack of explicit coverage by specific process documents. current list maintainer practice is only to block postings from operationally-disruptive sources. The IAB found that the response provided by the IESG in this action did not provide sufficient justification to sustain the banning of Mr. Morfin from the ietf-languages mailing list. .the IAB annuls the IESG's decision in this appeal and sends the matter back to the IESG for resolution. I can interpret this ruling in two possible ways: - The IAB has ruled that the IESG has not given sufficient justification for its decision to uphold the suspension of Jefsey Morfin, and that such a justification cannot include reference to rules that apply by analogy, but can only refer to common and reasonable practice - The IAB has ruled that it is not permissible for a mailing list maintainer to suspend anyone from an IETF-related mailing list for anything but operationally disruptive reasons as long as there is no specific rule authorizing such an action (A secondary question is whether offtopic postings can be considered operationally disruptive under the IAB's ruling. But if the first interpretation is correct, this does not matter.) Since I cannot tell which of the two rulings the IAB intended to hand down, I cannot tell what the proper action for an IAB-respecting list maintainer is until such a time that the IESG determines that there is IETF consensus for a practice for mailing list suspension on IETF non-WG mailing lists. I would appreciate a clarification from the IAB. Harald Alvestrand ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal of the IESG decision to publish draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
Dear Mr. Mehnle, This is to acknowledge receipt of your message. The IAB will review the material and provide you a response. Best regards, Leslie, IAB Chair. Julian Mehnle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To the Internet Architecture Board, as per the Internet Standards Process, section 6.5, and on behalf of the SPF project, I am hereby appealing the IESG's decision[2] on 2005-12-08 to publish the draft-lyon-senderid-core-01 I-D[3] as an Experimental RFC as-is. I am attaching my initial IESG appeal[1] and will try not to rehash all the arguments contained therein. I will merely point out the larger issues and the negative implications of the IESG's decision here. Please review the IESG appeal and the referenced documents first. The Problem === The IESG decision is wrong in two ways: 1. On a technical level, draft-lyon-senderid-core-01[3], by implicitly redefining the semantics of v=spf1 DNS records, significantly conflicts with draft-schlitt-spf-classic-02[4], on which the former depends, and which has also been approved by the IESG to be published as an Experimental RFC. The IESG has conceded this fact in their response[2] to my appeal, yet they argue that the IESG did consider this conflict in its original discussions, and that is one of the reasons why we crafted the original IESG note to be included in these documents, which highlights that there are concerns about using these mechanisms in tandem. No such note can sufficiently mitigate the technical conflict. Even though the IESG has only approved the drafts for Experimental status, the experiments they are approving are still in conflict. This conflict bears the potential of disrupting the e-mail operation of domain owners participating in either of the experiments despite their careful consideration of the experiments' rules. The IESG, under- standably, does not want to take sides for political reasons, but difficult political situations should not bar the internet standards process from producing technically sound results. The conflict arose only after the IESG asked for individual draft submissions from the SPF and Sender ID authors and draft-lyon-senderid- core-00 was submitted (which for the first time included the re-inter- pretation of v=spf1 records for the PRA identity). Accepting such a submission despite the prior consensus of the MARID WG[5] (which was closed afterwards) that v=spf1 should not be used for checking of PRA clearly violates the ultimate goal of producing reliable standards. 2. On an operational level, SPF has been an ongoing experiment since late 2003. In their response to my appeal, the IESG explained that the SPF and Sender ID drafts were approved for publication as Experimental RFCs and not approved for the Standards track, and that the bar is lower for Experimental RFCs. Ted Hardie, the IETF AD responsible for these drafts, explained[6] that the conflicts between the two [drafts] on this and other points are part of why the IESG is publishing them 'AS IS'. This reasoning disregards the substantial history the v=spf1 record definition has had outside the IETF since late 2003[7]. The SPF project, which I am representing in this case, believes that the decision to ignore the prior experience with SPFv1 and to lodge draft-schlitt-spf-classic for Experimental instead of Proposed Standard status was unjustified, but has accepted the IESG's decision that additional experience be gathered before standardizing the proposal. However the IESG's decision to equally publish a draft-lyon-senderid- core that, without technical reason, conflicts with the historical use of v=spf1 records, unnecessarily compromises at least one of the two experiments. Meaningful and reliable experience about the practicability and effectiveness of draft-schlitt-spf-classic cannot be reasonably expected to be collected when at the same time draft-lyon-senderid-core misinterprets the semantics of v=spf1 records in a significant number of cases. Requiring participants in the SPFv1 experiment to opt out from also participating in the Sender ID experiment by publishing an empty spf2.0 record cannot be considered an acceptable solution either, both based on principle and given the large number of existing v=spf1 records that were published before Sender ID was conceived[8]. Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, Experimental, requires verification that there has been adequate coordination with the standards process, which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. Both SPFv1 and Sender ID could
Second Call for Nominations: IETF-Selected ISOC Trustee
This is a Secondn Call for Nominations The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the IAB's process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 19: Open nominations period. February 22: Close of nominations period. Publication of list of nominated candidates. IAB commences consideration of candidates. On or before April 5: IAB selection delivered to IESG for confirmation. On or before May 3: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB -- [EMAIL PROTECTED] Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: Margaret Wasserman 2003 - 2006 (*) Eric Huizer 2004 - 2007 Fred Baker 2005 - 2008 (*) Current term expires in 2006 Leslie Daigle, Chair, IAB ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Second Call for Nominations: IETF-Selected ISOC Trustee
This is a Secondn Call for Nominations The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the IAB's process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 19: Open nominations period. February 22: Close of nominations period. Publication of list of nominated candidates. IAB commences consideration of candidates. On or before April 5: IAB selection delivered to IESG for confirmation. On or before May 3: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB -- [EMAIL PROTECTED] Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: Margaret Wasserman 2003 - 2006 (*) Eric Huizer 2004 - 2007 Fred Baker 2005 - 2008 (*) Current term expires in 2006 Leslie Daigle, Chair, IAB ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IAB Response to Appeal from Jefsey Morfin
in order to ensure that the IETF continues to function in the most open and fair manner possible, for all participants. 5. IAB Conclusion on the Appeal The IAB found that the response provided by the IESG in this action did not provide sufficient justification to sustain the banning of Mr. Morfin from the ietf-languages mailing list. In particular, while the IAB agrees with the IESG that no specific mailing list process RFCs directly apply in this case, its response is not sufficiently clear why RFC 3934 is considered applicable by analogy. Further, it is also unclear from the IESG's response what the scope of applicability of RFC 3934 might be, or when other process RFCs might be applied by analogy. Therefore, the IESG's action does not meet the clear and public requirement outlined above and the IAB annuls the IESG's decision in this appeal and sends the matter back to the IESG for resolution. Since the suspension period has expired, no remedy is indicated. However, the IAB recommends that the ambiguities that gave rise to this appeal be clarified, as described in the following sections. 6. IAB Recommendations 6.1 Clearly Define the Operation of IETF Mailing Lists If mailing list participation rules are to be based on contributing constructively to work items, the IETF should consider making public charters for those lists (however formal or informal) so that people understand the scope of the work, the person responsible for shepherding the discussion in accordance with the charter, and rules governing participation in those lists. In particular, future RFCs (or revisions of existing RFCs) governing mailing list administration should clearly indicate who the responsible parties are as well as the extent of their authorities. 6.2 Disambiguate Current Mailing List Administration Procedures The IAB recommends to the IETF that the ambiguity in the current procedures be cleared up. In particular: RFCs 3005 and 3934 allow for posting rights revocation for specific mailing lists (the IETF main list and working group mailing lists) at the discretion of people directly responsible to and appointed by the IESG; RFC 3683 allows for posting rights revocation by any IETF mailing list maintainer, but only on the basis of an IETF-wide consensus call (a high hurdle); current practice allows for posting rights revocation by mailing list maintainers in the case of operational emergencies; the large gap in between those procedures is not addressed, either by BCP or by well-established practice. 6.3 Clearly and Publicly Document IESG Decisions on Appeals When deciding similar cases in the future, the IAB recommends that the IESG give clear and public support for the basis of their decision, either by providing clear documentation of the interpretation of applicability of existing process or by referencing well-established current practice. Leslie Daigle, IAB Chair. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IAB Response to Appeal from Jefsey Morfin
Sam, One IAB member's perspective: no, the expectation is not BCP upon BCP upon BCP. The devil is, of course, in the details. Even community commented on published operational procedures should not be at odds with our general or specific process documents, or else that seems to suggest the process documents need updating. And we have a community-defined process for that (which seems to result in a BCP). Again -- that's just one person's perspective. Leslie. Sam Hartman wrote: So, a clarification request: Am I correctly understanding that the clear and public requirement does not always imply a process RFC? In particular, John Klensin has made an argument that there are a wide variety of matters that are better handled by operational procedures made available for community comment than by BCP document. It's my reading that the IAB is interested in making sure that the processes and rules are clear and public, not that they are all codified in BCP. I'm not looking for a formal response from the IAB but would appreciate comments from its members. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Call for Nominations: IETF-Selected ISOC Trustee
The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the IAB's process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 19: Open nominations period. February 22: Close of nominations period. Publication of list of nominated candidates. IAB commences consideration of candidates. On or before April 5: IAB selection delivered to IESG for confirmation. On or before May 3: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB -- [EMAIL PROTECTED] Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: Margaret Wasserman 2003 - 2006 (*) Eric Huizer 2004 - 2007 Fred Baker 2005 - 2008 (*) Current term expires in 2006 Leslie Daigle, Chair, IAB ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Impending publication: draft-iab-irtf-01.txt
The IAB is ready to ask the RFC-Editor to publish IAB Thoughts on the Role of the Internet Research Task Force (IRTF) draft-iab-irtf-01.txt as an Informational RFC. The chief purpose of this document was to collect and record a set of considerations the IAB discussed in the process of reviewing the IRTF Chair position last year. As such, it is not suggesting process or structure changes at this time, and is primarily intended to capture IAB state. Comments are therefore most likely to be of the form of suggestions for improving clarity. The IAB solicits comments by December 14, 2005. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-irtf-01.txt From the Abstract: This document is an IAB (Internet Architecture Board) report on the role of the IRTF (Internet Research Task Force), both on its own and in relationsip to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Update: IETF Trust Consensus Call
Forwarded on behalf of Lucy. Leslie. Original Message Subject: Update: IETF Trust Consensus Call Date: Wed, 23 Nov 2005 13:15:19 -0800 (PST) From: Lucy E. Lynch [EMAIL PROTECTED] To: ietf@ietf.org All - I would like to extend the Consensus Call on the IETF Trust for one additional week until December 2nd. Feedback to the IETF list has been sparse, but there has been some traffic on the IPR-WG list and a few comments directed to the IAOC. Additional clarification has been requested on several points related to future Licensing of IPR held by the IETF Trust and on the exact nature and disposition of both Current and Historical data as defined in Schedule A. The combination of IETF 64, WSIS related travel, and the coming US holiday has made it hard for all three parties to the IETF Trust (CNRI/ISOC/IAOC) to coordinate our responses on these two issues. We hope to have clarifying text on the Licensing issue and updates for the FAQ shortly, and will publish before 12/2/05. Watch this space: http://koi.uoregon.edu/~iaoc/ Thanks to all who have made comments, and we will keep you posted. Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF Trust update
[Posting on behalf of Lucy Lynch. -- LLD] The IAOC is pleased to announce that we have reached substantial agreement with both CNRI and ISOC on the founding document for an IETF Trust. The IETF Trust is a private legal construct (in this case established under the laws of Virginia, USA) allowing assets (in this case, intellectual property rights and other property) to be held and administered for the benefit of the IETF and hence the Internet standards process. The IETF Trust document, a model version of an IPR License (based on the potential Service Agreement with NeuStar for the provision of Secretariat services) and a short FAQ are available now on the IAOC web site: http://koi.uoregon.edu/~iaoc/ The FAQ is intended to be a living document and will be updated as questions come in from the community. Please address your questions and concerns to either [EMAIL PROTECTED] or directly to the IETF list (ietf@ietf.org). Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: [Pesci-discuss] Growing concerns about PESCI
Here's a specific aspect I'd like to hear the community at large thinking about, re. PESCI (please read all the way to the bottom to get the actual question; it may not be what you expect): We're not doing this as a WG because we (agreed we) don't like those nasty spiralling pointless and painful discussions of the current state of the lint in the IETF navel, and the lack of detectable consensus. We have a -discuss mailing list and a design team instead. On the -discuss list, the lead of the design team has asked folks to hash through issues, review the document, and contribute brain trust. Or: what a normal WG would be expected to do. The big difference is -- there is absolutely no piece of IETF standards process that *requires* that the design team listen to any of the points provided on the -discuss list. There is a tacit requirement, in that one presumes the appropriate AD will be recalled if the result is clearly and obviously out of step with what the community asks, but that's a high-risk negative motivation. So, a genuine question: is PESCI blurring lines, or does this suggest that we have in fact given up on WGs/our process? Leslie. John C Klensin wrote: Harald, I don't want to have this turn into a discussion among a handful of current or recent IESG or IAB members, so will respond to some of you note and then go quiet again. The bottom line, IMO, is that if others in the community are not concerned about this and willing to speak up, then PESCI and how it is being positioned are what the IETF wants and deserves... and so be it. --On Tuesday, 25 October, 2005 06:36 -0700 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Some notes on a couple of your points. --On 25. oktober 2005 08:48 -0400 John C Klensin [EMAIL PROTECTED] wrote: --- ... (1) Design teams tend to self-constitute although they can be selected. When they are selected by a WG Chair or AD, the membership criteria are usually clear and then followed. In this case, membership selection was filtered based, in part, on the participants not being an activist and, specifically, not having current drafts for reform. Yet the organizer has a reform draft, and is generating new versions of it, and is an exception. (20050923) I've never seen a design team that had clear mebership criteria. apart from the self-selecting variety, the versions I've seen have all been you look like good people; would you care to spend time here. Sure. But this isn't an ordinary design team. The IETF Chair issued a call for volunteers and explicitly stated criteria for selection that he then proceeded to violate (not just with himself but with you, since you are co-author of a process reform draft that has just been last-called and a significant contributor to some of the ISD/SRD work). Now perhaps the activist / author of drafts criterion should be interpreted much more narrowly as applying only to people who have proposed changes to the process approval mechanism and have written active drafts containing those proposals. That would exclude a somewhat smaller population, I think limited to me, but would have been an irrelevant criterion for PESCI membership selection since I did not volunteer. (Disclosure: I didn't volunteer not because I considered this hopeless or because I was convinced that Brian would not pick me (neither was the case), but because my travel and non-IETF commitment schedule over the last several months made it extremely unlikely that I could meet PESCI's workload requirements.) More important, there have been hints of the work of this effort being approved by extraordinary means, it is reasonably rare that a design team gets a BOF and then a significant block of plenary time to present and discuss the results of that BOF at the same IETF meeting, etc. Precisely because of the complications of the leadership roles, other activities of this effort need to be far more open, public, careful, and generally sensitive to an open process and IETF community involvement than usual. I remained silent because I hoped that level of sensitivity would prevail and that this would be efficient. I am not feeling very good about that right now. (3) The team is expected to report at the Plenary, partially on the basis of its BOF meeting, but the BOF ends only one 50-minute break before the plenary. Not exactly time for the team to meet, carefully consider the discussion at the BOF, and prepare a report. Indeed, while it is reasonable to hope for something else, this would appear to be a setup for the well, we just got a lot of input and are thinking about it, stay tuned reports that characterized the admin restructuring process. I very much agree. We specified must be before the Plenary in the request for a slot, and did not specify *how long* before the plenary - and got the (IMHO) worst possible time. Then we didn't flag this as
TechSpec BoF
FYI, I've updated the TechSpec BoF agenda to include the pointer to the mailing list to discuss the draft: Mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/techspec Draft draft-mankin-pub-req-00.txt (to be updated before Vancouver, based on input received so far) BoF: TechSpec -- Requirements for IETF Technical Specification Publication Chair: Leslie Daigle Mailing list: [EMAIL PROTECTED] The work of the IETF is to discuss, develop and disseminate technical specifications to support the Internet's operation. An important output of the IETF, then, is published technical specifications. As the IETF progresses, documentation and review of its requirements for the process and structure of technical specification publication is important in order to ensure continued support for the IETF's work. See the rest at: http://www3.ietf.org/proceedings/05nov/agenda/techspec.txt Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
As I've said on the other occasions I've had to see versions of Brian's proposal, My completely personal opinion: . it's reasonable for Brian to appoint a committee of whomever he wants, by whatever process he wants, to do whatever he wants . the outcome of that committee *MUST* fit in with our existing process: the IETF cannot be constrained to accept the output of that committee unless it has gone through full IETF review and existing process which I think is largely in agreement with what Ted and John have said, and isn't disagreeing with the text of Brian's statement. From here, the devil is in the implementation details, IMO: . how Brian will identify folks with (both) sufficient involvement and time to devote to produce a draft by IETF64; . how to have the public review of/input to any proposal(s) that has sufficient community engagement without ratholing (i.e., simply deferring all the aforementioned unsuccessful points of WGs) The first point is an oblique suggestion that we have patience in IETF64; the second is a suggestion of requirements. Leslie. John C Klensin wrote: Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:28 PM -0700 9/16/05, Dave Crocker wrote: And since all other public development efforts for process change have frankly fallen flat, as Brian has cited, what is your basis for believing that a working group charter will somehow make yet-another public process more effective at developing a specification for change? Possibly I'm wrong in this, but I believe that the public process works when the community cares about the outcome. The IASA work is done, and I believe it is a success because enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest-IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between sufficient people who care to do the work and a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right. That, to me, is the area of greatest difference between process WGs and engineering/ specification ones: with the latter, most of the people who get in there and do serious work are directly involved with the quality of the outcome (whether they do well or not is a separate matter). Process WGs
A question regarding IETF appointments
Annually, the IAB makes an appointment to one of three seats on the Internet Society Board of Trustees (ISOC BoT). BCP 77 (RFC 3677), which describes the selection process, allows IESG and IAB members to be selected for the ISOC Board, though no more than two of the three could be IESG or IAB members. In addition, BCP 10 (RFC 3777) in no way limits the NomCom from selecting sitting ISOC Board members to be on the IAB or IESG. There is a new relationship between ISOC and the IETF for administrative support as defined by BCP 101 (RFC 4071). Given these changes in our ties to ISOC, the IAB has been discussing (without coming to any conclusion on the matter) whether it is any longer appropriate for someone to simultaneously hold both an IAB/IESG position and a seat on the ISOC BoT. We think the community should discuss this. Note that if such a restriction is necessary, both BCP 77 and BCP 10 would need to be updated to reflect that. You are alway welcome to send comments privately to the IAB, but for the purposes of community *discussion*, please use this list (ietf@ietf.org). Leslie, for the IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Impending publication: draft-iab-link-indications-03.txt
The IAB is ready to ask the RFC-Editor to publish Architectural Implications of Link Indications draft-iab-link-indications-03.txt as an Informational RFC. A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document provides an overview of the role of link indications within the Internet Architecture, as well as considerations for their use, in order to preserve network robustness and performance. The IAB solicits comments by October 11, 2005. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-link-indications-03.txt From the Abstract: This document describes the role of link indications within the Internet Architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues and provides examples of appropriate and inappropriate uses of link layer indications. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Tech topics and plans for tonight's plenary
FYI, and to get people's minds in gear for tonight's technical discussion, here's the list of things we had suggested when we called for technical topics: 1/ The big interconnect -- voice and IP service provision (without re-running the VOIPEER bof). 2/ Does the IETF still follow (observe) the end-to-end and KISS principles? (e.g. sip, sipping, SBC, voipeer, ...) 3/ I'm seeing a whole new world of NAT-alikes popping up with Session Border Controllers, and would like to mention this to the community. So, think about the topics and what might be interesting to talk about, in them, that isn't going to take us down the ratholes we've explored thoroughly before (in plenary or various working groups). Perhaps harder than the technology itself ;-) . ie Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Actually, I'm not sure I agree (that it's a good plan, or better to do it this way than update the BCP). When the NomCom WG was discussing this as part of creating RFC3777, I was initially a proponent of the publish the candidate list! perspective. I will admit to having been swayed by the arguments that it increases the likelihood of scaring off potential candidates, requires the freezing the candidate list, exposes the nomcom to second guessing, and inevitably provokes electioneering. Further, I also wonder what happens *after* the NomCom selections are done. I.e., how many people will not have complaints taken seriously because they're just mad they were not selected. So, 1/ I'm not sure it's better to have a website that interested people can subscribe to at the cost of agreeing to maintain confidentiality than what we have today or going to a full open model. It has the chance of significantly increasing the whisper group, and doesn't really solve any of the negatives listed above. 2/ If we want to change the model, we should update the BCP, and take the time to consciously re-evaluate the upsides and downsides we know to exist with closed or open candidate lists. If we (the IETF community) genuinely want more openness, we should do that, and get on with dealing with the negative sides we know will exist. Let's not just go halfway and get the worst of both models. Leslie. Brian E Carpenter wrote: Soliman, Hesham wrote: At 01:10 PM 5/4/2005, Soliman, Hesham wrote: One way to open up the process would be to allow any participant to personally request a list of candidates from Nomcom, against a personal non-disclosure promise. (Not my idea; this was suggested during last week's IESG retreat.) = If we do that we may as well put the list on the web. How do we define participant? There is a difference between having participants who are interested in providing feedback ask for a copy of the list, with a promise of confidentiality, and give feedback - versus having that information publicly available. This sounds useful to me. I don't think that participant really needs to be defined. Those who will be interested are those who are involved. Currently, to obtain input from a more diverse set of people, Nomcomm has to guess who is appropriate to ask hope that a reasonable sampling of them will be willing/interested in responding. = Ok, since I think it will lead to the same effect (widely known nominees) I'm fine with that suggestion. Personally, I don't see the difference between doing what you describe above and sending the list of nominees to this mailing list. But either option is definitely better than what we have today IMHO. One difference is that we wouldn't have to update the BCP, since there would be no overt breach of confidentiality. So next year's NomCom could simply do this without further bureaucracy. I'm going to ask this year's Nomcom chair to see if this year's candidates can answer the question would you have run if your name had been made public? Brian ___ 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
IRTF Chair
As minuted for the October 2004 IAB meeting, Vern Paxson has decided to step down as IRTF Chair, effective this IETF meeting. The IAB would like to thank Vern for his 3 years of outstanding service in the IRTF Chair role, and we are pleased to announce the selection of Aaron Falk as the new IRTF Chair. Aaron has been an active member of the IETF community for almost a decade, including his current roles as DCCP WG chair and member of the RFC Editor group at ISI. A brief synopsis of Aaron's bio is provided below. The IAB has spent some months reviewing the IRTF structure with Vern (see draft-iab-irtf-00.txt), and we look forward to continuing to refine the IRTF with Aaron. Leslie Daigle, for the IAB. === Aaron Falk is a computer scientist conducting network research at USC Information Sciences Institute. His interests include network architecture, congestion control, and satellite networking. Aaron has been involved in the IETF since 1996, chairing the TCPSAT, PILC, and DCCP working groups and the RFC Editor contract at ISI. Aaron's background is in satellite system design and he developed satellite network architectures at TRW, Hughes, and PanAmSat. While at the University of Maryland, Aaron designed and implemented a system to provide broadband Internet access with a receive-only satellite dish. Aaron's current projects include implementing XCP, a new congestion control protocol, and exploring performance and functional issues when Internet protocols traverse packet-switching satellites. http://www.isi.edu/~falk ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
AMENDED: List of accepted nominations for IETF appointment to ISOC BoT
[My original announcement uncovered a glitch in communications in obtaining acceptance from one of the nominations we received for this position. I've amended the list for completeness, below.-- LLD] The procedure used by the Internet Architecture Board to select an individual toserve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process are: - Fred Baker - Scott Bradner - John Klensin - Jordi Palet Martinez - Marshall Rose Comments on these candidates may be submitted to the IAB until the 18th March. The IAB will make a selection by March 25, 2005, and pass this selection to theInternet Engineering Steering Group for confirmation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
List of accepted nominations for IETF appointment to ISOC BoT
The procedure used by the Internet Architecture Board to select an individual to serve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process are: - Fred Baker - Scott Bradner - John Klensin - Jordi Palet Martinez Comments on these candidates may be submitted to the IAB until the 18th March. The IAB will make a selection by March 25, 2005, and pass this selection to the Internet Engineering Steering Group for confirmation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IAB review of draft-ietf-iasa-bcp
The IAB has reviewed draft-ietf-iasa-bcp(-06) and supports the document going forward as the next step in the IETF's administrative restructuring process. The IAB is ready to undertake the roles and responsibilities assigned to it by the document. As part of the public discussion of this document, people have asked for various types of reviews of the document from the IAB. In making the statement above, the IAB is explicitly expressing its commitment to support the structure once the document is approved. While individual IAB members have contributed as participants in the community discussion, the IAB as a body is explicitly not attempting to gauge or express an opinion on the consensus of the community. The IAB has discussed whether it should undertake to do so for this particular document, and noting the role of the IAB as a point of appeal of IESG actions, its members were agreed that the task of assessing community consensus as input to an IESG decision remains outside the role of the IAB. Leslie Daigle, for the IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Controlled vs Managed (Re: ASCII diff of ISOC-proposed changes to BCP)
For myself, I find the arguments on both sides of controlled and managed to be compelling -- perhaps because I am not a lawyer. However, I am conscious that the words we write down are scrutinized and used by people the world over -- not always to our benefit, and often without any of the context that caused us to write them [*]. So, if the token really doesn't mean anything (per Jorge) because the import is in the text of the document, perhaps the right answer is to just *drop* that clause. This document describes the structure of the IETF Administrative Support Activity (IASA) as an [delete] activity housed within the Internet Society (ISOC). That makes the entire abstract: This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. I think this is still clear about where responsibilities lie; the document defines them in more detail; there is less possibility for misconception (by using either controlled or managed, depending on your perspective). Leslie. [*] A specific example, in a contribution to ITU re. e164.arpa: As can be seen from: http://www.iana.org/arpa-dom/e164.htm the domain e164.arpa is delegated to: Internet Architecture Board (IAB) c/o IETF Secretariat Corporation for National Research Initiatives (CNRI) 1895 Preston White Drive Suite 100 Reston, Virginia 20191-5434 The IAB has no legal personality of its own, nor does the IETF. So it would appear that the legal entity which can control changes to the entries under e164.arpa is the Corporation for National Research Initiatives (CNRI). The whois entry is written this way because the IAB has no (other) mailing address. It does *not* mean that CNRI is in control of the e164.arpa domain, but that's what this expression apparently means to people. It's this sort of thing that leads me to (personally) prefer the use of the term controlled, if we're going to use a term. But, if that term introduces misconceptions on the legal side, I'd rather just drop the whole thing. Harald Tveit Alvestrand wrote: --On 11. februar 2005 07:03 -0500 Margaret Wasserman [EMAIL PROTECTED] wrote: So, with my ISOC Board hat on (a hat which none of the ISOC Board members are legally allowed to take off), I am not inclined to ignore legal advice from ISOC's corporate counsel. Maybe the IETF Chair could ask the IETF lawyer (Jorge) whether changing the word from controlled to managed has any bad legal implications for the IETF? I asked Jorge, and here's what he said: this is a political point rather than a legal one. The precise nature of the control/management is described elsewhere, so this is just a characterization rather than operative (executable) language. So based on that advice, I'm not inclined to make a fuss over the term. but somewhat surprised that ISOC's lawyer thinks it's fuss-worthy. 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: ASCII diff of ISOC-proposed changes to BCP
A couple other comments: Fred Baker wrote: ISOC proposes to replace this: Within the constraints outlined above, all other details of how to structure this activity within ISOC (whether as a cost center, a department, or a formal subsidiary) shall be determined by ISOC in consultation with the IAOC. with this: Within the constraints outlined above, all other details of how to structure this activity within ISOC (whether as a cost center, a division, or a wholly controlled affiliate) shall be determined by ISOC in consultation with the IAOC. Again, I am not an expert here, but my reading of formal subsidiary and wholly controlled affiliate is not the same. The issue of control is a very sensitive one here, and I strongly suggest not using the term control here unless there is an extraordinarily strong reason to do so. This activity is controlled by the IETF in partnership with ISOC, through the offices of the IAOC. If there are other terms available that do not muddy those waters, I would strongly prefer that they are used. [snip] Maybe we can agree to call ISOC a non-profit corporation, and the IETF its affiliate? Legally, so I'm told (IANAL), the relationship doesn't change - ISOC is viewed as being legally in control and therefore legally whom to sue, and IETF is the child in the relationship. But we can sugar-coat that if it makes the fact more palatable. That would make the paragraph read Within the constraints outlined above, all other details of how to structure this activity (whether as a cost center, a division, or an affiliate) shall be determined by ISOC in consultation with the IAOC. This works for me. I wanted to comment because I believe I'm responsible for some original piece of this text, and the intent was simply to elaborate that the possibilities for implementation were varied and not part of what was being specified here. So, if one of the example forms was a bogon, it's important to replace it! Also, To try to minimize the change from the original edits, may I suggest this: Should the IETF standards process at some future date come to include other technical activities, the IAOC is responsible for developing plans to provide administrative support for them. Is that better? That probably makes more sense. BTW, ISOC and the IASA are logical places to look for such. But in this context IASA is the hands and feet and IAOC is the brain. So putting the responsibility with the IAOC is probably rational. FWIW, I like this proposal. I don't believe the intention was ever to create blank cheques, but the IASA as a whole is meant to be driven by the IETF's needs, and we shouldn't lose sight of that even as we give the IAOC the necessary tools to push back on things it can't do. I think this strikes the reasonable balance. Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IAOC Responsibilities
To emphasize something that Harald said -- my read of the discussion on this list is that the matter requires more discussion. It also requires more attention to detail than should go into the BCP. For example, from the discussion on the list, it's pretty clear that at least some people question the scope of the IPR that the IASA might manage -- *all* IETF IPR? IPR related only to administrative activities, what are the guidelines for managing it, etc. I think what this illustrates is that there is the need to start a separate effort to propose the codification of that management -- perhaps the IASA's first operational bcp, even if we start the discussion now. That would entail and allow a proper review of all proposals. Leslie. Harald Tveit Alvestrand wrote: Bob, neither your comment nor Patrice's comment reassure my stated concern that designating the IAOC as an entity that would be taking legal responsibility separate from ISOC would expose its members to personal liability. I believe that letting the BCP task the IASA with this responsibility allows it to decide - if it concludes that this is the best course for the IETF - to establish a trust that may have the IAOC members as trustees, or may have some different group as trustees, after due consideration of the liability issues, and without exposing its members to any liability that is not covered under the DO insurance that ISOC has contracted for, which covers all members of the IESG, IAB, Nomcom and WG chairs operating within the IETF process. It seems precipitate to me to insist that this specific organizational form be mandated in this document, rather than let the IAOC decide on its own whether or not to create such an entity after due deliberation. Could you explain why you think that the idea of a trust needs to be specified in the BCP, rather than assuming that the IASA will choose to establish one if it becomes clear that this is the best construct for the IETF? I do agree that the term belonging to the IETF is not the best language to use, given the IETF's decision not to formalize its legal status at this time. Harald --On 3. februar 2005 07:45 -0500 Robert Kahn [EMAIL PROTECTED] wrote: I continue to remain concerned that the BCP is not flexible enough to allow the IAOC to assume administrative responsibilities for acting as a trustee for IETF-owned IP. There needs to be a specific task added to the IAOC responsibilities for this purpose. Specifically, the following words should be added to the list of IAOC responsibilities: Serve as Trustee for IETF assets including, without limitation, intellectual property and domain names. Patrice's comment below is particularly important where licensing and other management tasks related to donated patents are concerned. Simply designating IASA to be responsible has too many operational problems to be workable in practice. In light of the interrelationship between the administration of IETF assets and the potential impact on IETF Standards activities, the IAOC should retain the primary responsibility for managing IETF assets in the first instance, even if the IAOC were to delegate the day to day administrative tasks such as sublicensing to others (e.g. to the IAD). Bob -- From: Patrice Lyons [EMAIL PROTECTED] To: Robert Kahn [EMAIL PROTECTED] Subject: IP matters Bob, There is a recent discussion on the IETF list that raises certain questions. In particular, take a look at the statement: The IASA is responsible for managing all intellectual property rights (IPR) . . . that belong to the IETF. Since the IETF is not incorporated, it is at best unclear whether the IETF is capable of owning copyrights, patents, trademarks or any other rights or interests. There are simple procedures that may be required to enable this such as filing appropriate documents with the Virginia state authorities. Also, since the IASA does not appear to be a legal person, but rather an activity or process having two components: IAD and IAOC, where would the responsibility for managing the so-called IPR reside in the first instance and who would decide? For example, if the IAD is an employee of ISOC, a license agreement between the IETF and ISOC would be required to authorize the IAD to use the IETF marks and to sublicense the marks to IETF service providers. Who has signature authority for this purpose? From a CNRI perspective, it would appear prudent to task the IAOC with the responsibility for entering into such a license agreement with ISOC, and to oversee quality of service standards with respect to the activities of the IAD using the IETF marks. Regards, Patrice Lyons ___ 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: Monday consensus text: #725 Appealing decisions
Howdy, I'm a little concerned about hacking the appeals path on the fly (i.e., dropping the IESG and going straight to IAB), but I can live with that. WRT this: Harald Tveit Alvestrand wrote: - Removed the para about metrics. That's not part of this section. Could go under IAD responsibilities. But I think they're not critical. I think it should appear in the document. Either in the IAD responsibilities (as you've suggested), or I can send more text as to how it pertains to appeals. That is, it's easier to avoid appeals when there is concrete data on the table, and/or support them where appropriate. I don't think people want more text at this point. So, perhaps just putting it in the IAD section is the easiest path at this time. Leslie. Harald Tveit Alvestrand wrote: Lots of commentary on this one, some principle-based, some pointing out where the text-as-written said something that was Obviously Wrong. I've tuned the text below to: - Removed the para about metrics. That's not part of this section. Could go under IAD responsibilities. But I think they're not critical. - Go straight to the IAB on the appeals path. - Clarified that do nothing but answer is a valid option when responding - Changed initiate work on changing the BCP to recommend to the comnunity that the BCPs should be changed Most responses on the list have spoken in favour of leaving the last section (overturn decisions) in; John pointed out that it's completely unclear what the real rules for this type of action is. And I still don't like it. Still - I think this is a text that is possible to live with. 3.5 Review and Appeal of IAD and IAOC Decision 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 operational decision making. Where appropriate, these guidelines should be developed with public input. In all cases, they must be made public. In the case where someone questions whether a decision or action of the IAD or the IAOC has been undertaken in accordance with IETF BCPs or IASA operational guidelines (including the question of whether appropriate guidelines have been created or maintained), he or she may ask the IAOC for a formal review of the decision or action. The request for review is addressed to the IAOC chair and should include a description of the decision or action to be reviewed, an explanation of how, in the requestor's opinion, the decision or action violates the BCPs or operational guidelines, and a suggestion for how the situation could be rectified. All requests for review will be publicly posted, and the IAOC is expected to respond to these requests within a reasonable period, typically within 90 days. It is up to the IAOC to determine what type of review and response is required, based on the nature of the review request. Based on the results of the review, the IAOC may choose to overturn their own decision, change their operational guidelines to prevent further misunderstandings, take other action as appropriate, or just publish the review result and take no other action. If a member of the community is not satisfied with the IAOC's response to his or her review request, he or she may escalate the issue by appealing the decision or action to the IAB, using the appeals procedures outlined in RFC 2026 [RFC2026]. If he or she is not satisfied with the IAB response, he or she can escalate the issue to the ISOC Board of Trustees, as described in RFC 2026. The reviewing body (IAB or ISOC BoT) will review the decision of the IAD or IAOC to determine whether it was made in accordance with existing BCPs and operational guidelines. As a result of this review, the reviewing body may recommend to the community that the BCPs governing IAOC actions should be changed. It may also advise the IAOC to modify existing operational guidelines to avoid similar issues in the future and/or may advise the IAOC to re-consider their decision or action. It may also recommend that no action be taken based on the review. In exceptional cases, when no other recourse seems reasonable, the reviewing body may overturn or reverse a non-binding decision or action of the IAOC. This should be done after careful consideration and consultation with the IAOC regarding the ramifications of this action. In no circumstances may the IESG or IAB overturn a decision of the IAOC that involves a binding contract or overturn a personnel- related action (such as hiring, firing, promotion, demotion, performance reviews, salary adjustments, etc.). Comments? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf
Re: Monday consensus text: #725 Appealing decisions
Howdy, I can't entirely agree with the argumentation, in part because (and again this goes back to how the text first appeared) metrics are useful to establish the state of the system, whether to critique the state or simply understand it. Appeal is only one form of critique. That said -- I'm not planning to say any more on the subject. It's not something I'm suggesting should stop the document, either way! Leslie. John C Klensin wrote: --On Monday, 31 January, 2005 14:00 -0500 Leslie Daigle [EMAIL PROTECTED] wrote: Howdy, I'm a little concerned about hacking the appeals path on the fly (i.e., dropping the IESG and going straight to IAB), but I can live with that. WRT this: Harald Tveit Alvestrand wrote: - Removed the para about metrics. That's not part of this section. Could go under IAD responsibilities. But I think they're not critical. I think it should appear in the document. Either in the IAD responsibilities (as you've suggested), or I can send more text as to how it pertains to appeals. That is, it's easier to avoid appeals when there is concrete data on the table, and/or support them where appropriate. I don't think people want more text at this point. So, perhaps just putting it in the IAD section is the easiest path at this time. Leslie, FWIW, in the spirit of Sam's note, I'd like to suggest that this doesn't belong in the document at all, but in some informal list of things we expect the IAD to do and will hold her or him (and the IAOC) accountable if enough of it isn't done. That is the less text rather than no more theme. I don't consider that a showstopper one way or the other, however... If it is to be put in as an IAD responsibility, it needs to be clear that better measurement is _not_ more important than getting the job done. My version of your comment about appeals is that, if the job is being done, and done well, meaningful appeals won't happen. If it is not being done, then the major benefit of extensive data is either to help prove that it isn't being done (which will probably be obvious) or to aid in telling those launching the appeal to go away... the latter if extensive, but irrelevant, data are collected. And I note that the original text did not require relevant metrics, interpretable metrics, or the like, just metrics. It shouldn't: those terms are nearly meaningless without careful definitions, and attempting to make those definitions would draw us into more and more detail that doesn't belong in the BCP even if we could agree on them.But there will be metrics don't necessarily aid in getting the job done and may actually impede it. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
Sam, For myself, I agree these things are true. I would like to believe they are obvious, though I'm not certain of that. For example, these things are equally true of the IAB and IESG, but it's not clear to me that everyone understands they can drop a note to either of those groups. I don't (personally) think the BCP is the place to try to capture this in more detail; perhaps there is some place to do so. Leslie. Sam Hartman wrote: Here is what I want in addition to Margaret's formulation. I want to see if I can get agreement on these (I suspect the answer will be yes) before working on text. IT may turn out that the BCP is the wrong place for such text. * The IAOC can choose to overturn or otherwise act to reverse a decision if it believes that is the best course of action to follow. Examples include changing procedures if they happen not to work very well or attempting to buy out or terminate a contract if it is clear that the contract is no longer in the IASA's best interest. * Members of the IAOC may take into account comments from the community and may decide to reconsider a decision based on such comments even if no formal requirement to review the decision or to respond to the comments exists. In other words if the community convinces the IAOC they were wrong, it is reasonable for the IAOC to go do something about it. * The IAOC should listen to comments. By this I mean that they should be aware of comments they are receiving and weight them according to their value. It's fine to ignore pointless comments; probably even fine to pay less attention to comments from people who have a track record of not providing useful input. It would not be desirable for the IAOC to have completely ignored a constructive, well-reasoned comment simply because there was no formal obligation to respond to the comment. (The IAOC still might not respond, but someone should have at least read the comment and considered what it said) * It is reasonable for individuals, groups or organized bodies to comment to the community and the IAOC on IAOC decisions. For example if the IAOC selected a meeting sight according to its criteria and the IESG noticed that many working group chairs and document authors were unwilling to come to this sight, it would be reasonable for the IESG to inform the IAOC of this observation. Depending on costs of canceling a meeting, it might (although probably would not) be reasonable for the IESG to ask the IAOC to reconsider. When I phrase things this way instead of in thinking about them in the context of formal appeals and reviews, they become stunningly obvious at least for me. If these things are not true, I don't think we are living up to an open transparent process receptive to the needs of the IETF community. On the other hand, these things are sufficiently obvious that perhaps nothing needs to be said about them. There is one area where text might be useful. I'd feel more comfortable if we added text encouraging members of the community with comments about decisions to make those comments to the community at large and/or the IAOC even if their comments did not meet the criteria for formal review/appeal. Sorry to run such a long chase and end up back mostly at nothing. --Sam ___ 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
Since I am responsible for some of this text, let me add a couple of comments, in-line: John C Klensin wrote: 3.5 Review and Appeal of IAD and IAOC Decision 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 operational 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 that there are reported objective performance metrics for all IETF administrative support activities. Back when I was actively doing political science, the belief that everything could be reduced to objective and quantifiable terms (the latter is what metrics means; if it isn't what was intended, some other word should be chosen) statements like this were described as physics envy.The statement would be reasonable if whenever feasible or the equivalent appeared there somewhere -- we _can_ evaluate the IAOC on its interpretation of feasible and how far they are willing to go to satisfy the needs or curiosity of the community. The Additionally... sentence came in when I had a section that was about responsiveness to the IETF community. The intent was that there should be metrics (and I do mean metrics) maintained with regard to various objective processes: RFC Ed queue, IANA queue, etc. This allows the community as a whole to have some insight into how the overall IETF machine is functioning. Now that the section is about appeal and decision review, the text may be a little out of place. Or not -- because one should be able to flag when the whole system just doesn't seem to be cutting it. So perhaps it's a wording problem. I'm not inspired with alternatives. ... on the nature of the review request. Based on the results of the review, the IAOC may choose to overturn their own decision and/or to change their operational guidelines to prevent further misunderstandings. This doesn't give the IAOC the option of saying no, you are wrong [because...], and we aren't going to change anything. Combined with other text above, that would imply that any member of the community can force the IAOC into either changing a decision or changing the operational guidelines. The IAOC must be able to say no you are wrong. If must even be able to say you have raised fifteen objections in the last 30 days, all of which have been turned down by us and everyone in the appeals chain, please go improve you sand-pounding skills. Agreed -- and I think Scott Brim flagged a different aspect of the same problem. I don't think there is anything intentional in not expanding this to include other options at the discretion of the IAOC. Perhaps removing it (as Scott suggested) is best. Personally, I'm as happy to leave those options in as explicit (but not limiting) examples. Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
I like this formulation. A couple of suggested tweaks, inline: Margaret Wasserman wrote: Remove the current sections 3.5 and 3.6 and replace them with a new section 3.5: 3.5 Review and Appeal of IAD and IAOC Decision 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 operational 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 administrative support activities. In the case where someone questions that a decision or action of the IAD or the IAOC has been undertaken in accordance with IETF BCPs or IASA operational guidelines (including the creation and maintenance of an appropriate set of operational guidelines), he or she may ask the IAOC for a formal review of the decision or action. The request for review is addressed to the IAOC chair and should include a description of the decision or action to be reviewed, an explanation of how the decision or action violates the BCPs or operational guidelines, and a suggestion for how the situation could be rectified. All requests for review will be publicly posted, and the IAOC is expected to respond to these requests within a reasonable period, typically within 90 days. It is up to the IAOC to determine what type of review and response is required, based on the nature of the review request. Based on the results of the review, the IAOC may choose to overturn their own decision and/or to change their operational guidelines to prevent further misunderstandings. If a member of the community is not satisfied with the IAOC's response to his or her review request, he or she may escalate the issue by appealing the decision or action to the IESG, using the appeals procedures outlined in RFC 2026 [RFC2026]. If he or she is not satisfied with the IESG response, he or she can escalate the issue to the IAB and on the ISOC Board of Trustees, as described in RFC 2026. The IESG, IAB or ISOC BoT will review the decision of the IAD or IAOC I'm stumbling over the IESG, IAB or ISOC BoT. I understand you're saying whichever it is at this level of the appeal, but it comes off sounding a bit like whoever gets around to replying. Perhaps it could be rewritten as: The reviewing body (IESG, IAB or ISOC BoT, as appropriate) will ... and then subsequent instances of IESG, IAB... would be replaced with the reviewing body? to determine whether it was made in accordance with existing BCPs and operational guidelines. As a result of this review, the IESG, IAB or ISOC BoT may decide to initiate changes to the BCPs governing IAOC actions. I suggest spelling out the initiate changes -- ...may decide to initiate the required public consensus process to change the BCPs... They may also advise the IAOC to modify existing operational guidelines to avoid similar issues in the future and/or may advise the IAOC to re-consider their decision or action. In exceptional cases, when no other recourse seems reasonable, the IESG, IAB or ISOC BoT may overturn or reverse a non-binding decision or action of the IAOC. This should be done after careful consideration and consultation with the IAOC regarding the ramifications of this action. In no circumstances may the IESG or IAB overturn a decision of the IAOC that involves a binding contract or overturn a personnel-related action (such as hiring, firing, promotion, demotion, performance reviews, salary adjustments, etc.). [The last paragraph is likely to be the most controversial, as I am not sure that we have consensus that the IAB or IESG should be able to overturn or reverse a decision or action of the IAOC at all.] Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
Avri, I hear what you are saying. I retained the proposed text for being obliged to respond only when direct by IAB/IESG because people seemed to want it for rate limiting (i.e., preventing DoS). So, we can't just throw it out. We can change it (entirely), but the empty set option does not seem to meet other requirements expressed here. The one further adjustment I think I would suggest to my text of yesterday is to change Answered requests... made public to All requests...made public. I.e., it should not be possible for the IAD/IAOC to sweep issues under a carpet. Personally, I believe that does make the IASA ultimately accountable to the IETF community as a whole, even if it is not *instantaneously* accountable to the IETF community for every decision. And I think it is important that we not lose sight of the other things my proposed text attempted to capture and distinguish. Leslie. [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, 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Progressing Re: Progress report......
I believe the scenarios you are outlining are certainly possible. I don't (personally) believe that we can write rules or process steps to make them impossible. I also am concsiously saying possible without any prejudice about likelihood. That is -- I have no opinion about the likelihood of these possible outcomes. Because we can not make these things impossible, the only thing we can reasonably do is apply judgement. In this case, I believe that requires having a designated human being (or small group of human beings) sit down and discuss with the parties involved. These designated folks have to apply judgement and take action based on their understanding of the situation. As I understand it, that designated person/group are: the IAD and IAOC. That was a long-winded way of saying: these are justified concerns, but we are not as a group going to be able to prove our way out of them; even the IAD-to-be is going to have to say in my judgement, we should do X. So, to the earlier comment about negotiating backroom closed deals: I don't recognize anything in what has been done/is being proposed that fits that description. My message last Friday aimed to do 3 things: . publicize that the transition team is (nothing more than) aware of some ongoing CNRI-NeuStar negotiations . provide a list of expected operational guidelines for secretariat services in 2005, irrespective of provider . observe that, from informal discussions we've had so far, and given other factors (e.g., continuity), we (the transition team) can envision a future where it would be a reasonable thing to engage in a contract with NeuStar-post-CNRI-deal that would live up to those operational guidelines. But the proof is still in the pudding: we (IETF in general, TT in particular) have not seen so much as a draft of a proposed contract for 2005 Secretariat services, from anyone. It is our anticipation that the order of operations would be: 1. a contract will be proposed, and negotiated by the IAD 2. if such negotiations lead to a final contract that is consistent with those guidelines (including ability to apply performance review), we have an option to pursue 3. if said negotiations do not yield such a contract, or if no such contract proposal appears reasonably soon, the IASA (on behalf of the IETF) is going to have to strike out and develop an independent RFP process if it is to meet the requirements of the BCP. Given Bob Kahn's recent message, I think people reading this list will understand that there would likely be resistance from CNRI to point #3. I personally believe we *all* benefit from making #2 work (including the requirement that the contract moves us beyond where we have been for the last N years with Secretariat, and is in line with what the IASA is supposed to be about). But we are still talking about work that *will* have to be done (negotiating) -- there are no secrets to be exposed from backrooms in terms of deals cut already. At least, not that I am aware of! Leslie. John C Klensin wrote: --On Wednesday, 26 January, 2005 17:04 +0100 Wijnen, Bert (Bert) [EMAIL PROTECTED] wrote: John writes: ... snip a lot .. I'd rather either * Fix the BCP to accommodate this case, i.e., to give the IAOC the authority to accept unsolicited, sole-source proposals for outsourced operations if that seems appropriate to them, even if those proposals do not fufill some of the principles of the BCP itself or * Bury the BCP, at least in its present form, until we are really ready to move forward with its provisions. The first of those options would, of course, respond to my question about how the community authorizes this type of deal: we examine the principles and give the IAOC the authority to do it. It seems to me that we (as IETF community) have no formal control at all over what CNRI/Fortec do. So why would we as a community have (or need) any say over what CNRI/Neustar do? All we need to do is that as soon as we have IASA in place (we still need to approve the BCP first) that IASA then starts to prepare for RFPs and such and then the process can start. During that process, we are still subject to whatever CNRI/Foretec/Neustar do, are we not? Absolutely. But there have been several suggestions that Neustar wants a guarantee of a year or two _from the IETF_ for them (and Foretec) to keep the secretariat for them to go ahead with the deal. If they get that guarantee from somewhere, the RFP preparation process is either moot or at least hugely dragged out. In principle, they might alternately get a guarantee from CNRI to fight any attempt to move the secretariat elsewhere with every tool, IPR claim, etc., at CNRI's disposal. Or they might guarantee
Re: Mud. Clear as. Re: Rough consensus? #425 3.5
Sam, Let me first take another stab at recap'ing the discussion that lead to my proposal for 3.5 and 3.6, and clarifying what I intend as a distinction between them. As I understood them, John Klensin, Mike St.Johns, and others were concerned about creating an IASA that could not or operate without constant checking by the IETF community (having their feet shot at, in the worst case). That makes sense to me -- the IASA, as a separate activity, should have clear boundaries of responsibility. The IETF community as a whole should not become the invisible hands driving the IASA actions. This is the intent of section 3.5. At the same time, the IASA is meant to be responsive to the IETF, and should not be able to lose track of that. We should have a mechanism for expressing when we think the IASA is not behaving according to its rules (the BCP, and operational guidelines it develops to carry out those functions). This is the intent of section 3.6 So, I don't (personally) expect a future where individual IETF participants can derail a proposed meeting site because they don't agree with it. However, individual IETF members should be able to point out that a proposed meeting site selection is not in line with state operational guidelines for picking meeting sites (which might include proposing them publicly for 2 weeks before finalizing, for eg). To your specific question of how my proposed 3.5 and 3.6 (reproduced below for those who didn't memorize them) fit with Margaret's notes: [Margaret wrote:] (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. Well, I disagree that it makes the community impotent. See my note to Avri today. My text does attempt to make clear what level individual IETF members should get involved at. So, the intent of my proposed text is to not only prevent undoing of signed contracts, but also say that the IETF in general should not be focused on every action that leads to such contracts. I believe this is a point where Margaret and I disagree. (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 seem to find that process confusing enough that they don't often get it right). Section 3.6 attempts to be clear about its review process. It may not be sufficiently detailed. I think it is probably detailed enough for the RFC. (Further detail could be... operational guidelines). (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. I believe my text agrees with that. I'm positing that best interests of the ietf are captured in the BCP and the operational guidelines; to the extent that they do not, then it would be hard for the IASA to know what it was supposed to have done. This may mean that operational guidelines need to be created or updated for future situations. (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. I think the latter is achievable under 3.6, or a very slight modification thereof. Earlier today I suggested that I thought the last Answered requests... should be modified to All requests..., and it's not a big step from there to saying that all requests are answered even with a short statement like hte last. I don't have an issue with that. Others concerned about DoS attacks might. (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
Mud. Clear as. Re: Rough consensus? #425 3.5
position is that they act as channelers. I am not personally strongly wedded to this -- it's a leftover from previous discussion. Leslie. Leslie Daigle wrote: Following up the point I made in response to Mike St.Johns a couple days ago, I went back through the document to see if/how it distinguishes between being adequately responsive and accountable to the community, from having appropriate chains of accountability for contractual purposes (and no micromanagement of the business affairs of the IASA). It seems to me that we should: 1/ Change this section: 3.3 Relationship of the IAOC to Existing IETF Leadership to 3.6 Responsiveness of IASA to the IETF and include the original text plus Harald's text adjusted to be about the general processes. And a point about objective process metrics. 2/ Add a section (3.5) specifically about business decisions -- which, as Mike St.Johns pointed out, should remain within the IAD/IAOC. That would make: 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 to include voting records 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. However, the nature of the IAOC's work involves treating the IESG and IAB as major internal customers of the administrative support services. 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. In order to achieve this, the IASA should ensure there are reported objective performance metrics for all IETF process supporting activities. In the case where someone questions an action of the IAD or the IAOC in meeting the IETF requirements as outlined above, 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. Leslie. Leslie Daigle wrote: Interesting... To the extent that the IAD and IAOC are dealing with decisions about implementing requirements, I agree. To the extent that the IAD and IAOC are applying judgement to interpret the best needs of the IETF (i.e., determining those requirements), I disagree. I think it's a little heavy-handed to have to instigate a recall procedure if the IAD (or IAOC) seem not to have heard the *community's* requirements for meeting location. So, (how) can we make the distinction without creating a decision tree of epic proportions? Leslie. Michael StJohns wrote: Hi Harald et al - I apologize for chiming in on this so late, but I had hopes it would get worked out without me pushing over apple carts. I can't support this and I recommend deleting this section in its entirety. My cut on this: The decisions of the IAD should be subject to review (and in some cases ratification) ONLY by the IAOC. The decisions of the IAOC should not be subject to further review by the IETF at large. The proper venue for expressing tangible displeasure with a decision is during the appointment and reappointment process. (Note, I'm not precluding pre-decision comment by the community at large, and I encourage the IAOC to seek such comment where appropriate but once the decision is made its time to stop whining and get on with things) The decisions of the IAOC must be publicly documented to include voting records for each formal action. The IAOC and IAD must accept public or private comment but there is no requirement to either respond or comment on such missives. The IAOC and IAD should not be subject to the IETF appeals process. The appropriate venue for egregious enough complaints on the commercial side is the legal system or the recall process. My reasoning: The IAD and IAOC are making commercial (as opposed to standards) decisions and the result of that may be contracts or other commercial relationships. Its inappropriate in the extreme to insert a third (or fourth or fifth) party into that relationship. The IAD/IAOC relationship is going to be somewhat one of employee/employer and its inappropriate to insert external parties into that relationship. The documentation requirement is so that when the appointment process happens there will be some audit trail as to who did what to whom. The IETF appeals process is not appropriate for a commercial action. A standards action may
IASA Transition Team update on Secretariat 2005
As part of its work to look at potential agreements with service providers, the IASA Transition Team has been reviewing the possibilities for IETF secretariat functions for 2005. As you have heard, CNRI has committed to running the IETF Secretariat for 2005, as it has done in the past, unless and until a suitable alternate arrangement is established. The IASA Transition Team has been informed by CNRI and NeuStar that discussions are underway to sell Foretec to NeuStar, after which NeuStar would create a new, non-profit company with the intent of offering continuing Secretariat services to the IETF with changed management and under new rules of financial transparency and management control. To date, we are unaware of any binding agreements having been made between CNRI and NeuStar. The IASA TT observes that this arrangement would have the advantage of preserving the continuity of the Secretariat operation and ensuring that both the 2005 meeting schedule and the ongoing support of the IESG and working groups proceed without interruption. At the same time, a very large portion of the goals of the Administrative Restructuring effort would be accomplished. Specifically, within the next few months: o The IASA operation will be in place as an IETF-controlled activity within the Internet Society o There will be full financial transparency and accountability o There will be full management accountability o All future intellectual property will be unequivocally accessible to the IETF and the community. Therefore, the Transition Team is favorably inclined to consider a proposal from NeuStar for continuing Secretariat services under very specific conditions. 1. This arrangement would be for a limited period of time, after which the IASA will review the performance and proceed to an open RFP (in which this new company could reasonably compete) 2. The operating relationship between the IASA and the NeuStar entity would be based on the IASA-Secretariat relationship framework described below. Leslie, for The IASA Transition Team -- Proposed IASA-Secretariat relationship framework Upon establishment of the IASA, it (or the appropriate component of the IASA, as defined by the BCP) will interact with the organization(s) providing secretariat services as follows: 1. The IASA, on behalf of the IETF expects to operate under a written agreement with the provider(s) of IETF secretariat functions. 2. The IASA will be accountable for all money received and expended on behalf of the IETF (as described in the IASA BCP). This necessarily means that the IASA is responsible for decisions related to expenditures. Implementation details for decision making, requests, and authorization will be defined in the written agreement(s) between IASA and the provider(s). 2.1 The IASA will approve new meeting location proposals. 2.2 The IASA will manage proposals for administrative infrastructure improvements (software, tools requirements and expenditures). 2.3 The IASA will be responsible for maintaining the IETF administrative work descriptions and assignments, beyond the existing definition of secretariat activities. 3. The IASA will evaluate the performance of the services and will make decisions for service continuation or termination. 4. In principle, all data and any other IPR created or collected on behalf of the IETF for secretariat purposes will be made accessible to the IASA on a regular basis, and the IASA may make that data available to other parties to perform activities not included in the secretariat functions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Rough consensus? #425 3.5
Following up the point I made in response to Mike St.Johns a couple days ago, I went back through the document to see if/how it distinguishes between being adequately responsive and accountable to the community, from having appropriate chains of accountability for contractual purposes (and no micromanagement of the business affairs of the IASA). It seems to me that we should: 1/ Change this section: 3.3 Relationship of the IAOC to Existing IETF Leadership to 3.6 Responsiveness of IASA to the IETF and include the original text plus Harald's text adjusted to be about the general processes. And a point about objective process metrics. 2/ Add a section (3.5) specifically about business decisions -- which, as Mike St.Johns pointed out, should remain within the IAD/IAOC. That would make: 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 to include voting records 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. However, the nature of the IAOC's work involves treating the IESG and IAB as major internal customers of the administrative support services. 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. In order to achieve this, the IASA should ensure there are reported objective performance metrics for all IETF process supporting activities. In the case where someone questions an action of the IAD or the IAOC in meeting the IETF requirements as outlined above, 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. Leslie. Leslie Daigle wrote: Interesting... To the extent that the IAD and IAOC are dealing with decisions about implementing requirements, I agree. To the extent that the IAD and IAOC are applying judgement to interpret the best needs of the IETF (i.e., determining those requirements), I disagree. I think it's a little heavy-handed to have to instigate a recall procedure if the IAD (or IAOC) seem not to have heard the *community's* requirements for meeting location. So, (how) can we make the distinction without creating a decision tree of epic proportions? Leslie. Michael StJohns wrote: Hi Harald et al - I apologize for chiming in on this so late, but I had hopes it would get worked out without me pushing over apple carts. I can't support this and I recommend deleting this section in its entirety. My cut on this: The decisions of the IAD should be subject to review (and in some cases ratification) ONLY by the IAOC. The decisions of the IAOC should not be subject to further review by the IETF at large. The proper venue for expressing tangible displeasure with a decision is during the appointment and reappointment process. (Note, I'm not precluding pre-decision comment by the community at large, and I encourage the IAOC to seek such comment where appropriate but once the decision is made its time to stop whining and get on with things) The decisions of the IAOC must be publicly documented to include voting records for each formal action. The IAOC and IAD must accept public or private comment but there is no requirement to either respond or comment on such missives. The IAOC and IAD should not be subject to the IETF appeals process. The appropriate venue for egregious enough complaints on the commercial side is the legal system or the recall process. My reasoning: The IAD and IAOC are making commercial (as opposed to standards) decisions and the result of that may be contracts or other commercial relationships. Its inappropriate in the extreme to insert a third (or fourth or fifth) party into that relationship. The IAD/IAOC relationship is going to be somewhat one of employee/employer and its inappropriate to insert external parties into that relationship. The documentation requirement is so that when the appointment process happens there will be some audit trail as to who did what to whom. The IETF appeals process is not appropriate for a commercial action. A standards action may adversely affect competitors across a broad spectrum of companies. This commercial action only affects the bidders or winners. Please, let's get the IETF
Re: Rough consensus? #425 3.5
Interesting... To the extent that the IAD and IAOC are dealing with decisions about implementing requirements, I agree. To the extent that the IAD and IAOC are applying judgement to interpret the best needs of the IETF (i.e., determining those requirements), I disagree. I think it's a little heavy-handed to have to instigate a recall procedure if the IAD (or IAOC) seem not to have heard the *community's* requirements for meeting location. So, (how) can we make the distinction without creating a decision tree of epic proportions? Leslie. Michael StJohns wrote: Hi Harald et al - I apologize for chiming in on this so late, but I had hopes it would get worked out without me pushing over apple carts. I can't support this and I recommend deleting this section in its entirety. My cut on this: The decisions of the IAD should be subject to review (and in some cases ratification) ONLY by the IAOC. The decisions of the IAOC should not be subject to further review by the IETF at large. The proper venue for expressing tangible displeasure with a decision is during the appointment and reappointment process. (Note, I'm not precluding pre-decision comment by the community at large, and I encourage the IAOC to seek such comment where appropriate but once the decision is made its time to stop whining and get on with things) The decisions of the IAOC must be publicly documented to include voting records for each formal action. The IAOC and IAD must accept public or private comment but there is no requirement to either respond or comment on such missives. The IAOC and IAD should not be subject to the IETF appeals process. The appropriate venue for egregious enough complaints on the commercial side is the legal system or the recall process. My reasoning: The IAD and IAOC are making commercial (as opposed to standards) decisions and the result of that may be contracts or other commercial relationships. Its inappropriate in the extreme to insert a third (or fourth or fifth) party into that relationship. The IAD/IAOC relationship is going to be somewhat one of employee/employer and its inappropriate to insert external parties into that relationship. The documentation requirement is so that when the appointment process happens there will be some audit trail as to who did what to whom. The IETF appeals process is not appropriate for a commercial action. A standards action may adversely affect competitors across a broad spectrum of companies. This commercial action only affects the bidders or winners. Please, let's get the IETF out of the metaphorical administrative back seat and get them back to doing what they do well - technology. At 05:47 AM 1/19/2005, Harald Tveit Alvestrand wrote: Trying to close this item, which is not resolved in the -04 draft: I believe that the list discussion has converged on very rough consensus (Sam and Avri being the people who worry that we're building a DoS attack defense that we don't need, but Brian, Scott and John Klensin, at least, strongly arguing that we need that mechanism) on the following text, which I suggested on Jan 13, replacing the last 3 paragraphs of section 3.4: -- 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. --- Can we live with this? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Call for Nominations: IETF-Nominated ISOC Trustee
Call for Nominations: IETF-Nominated ISOC Trustee The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. A description of the process for selecting the Trustee each year can be found in RFC3677. Timetable - The timeline the IAB is using this year is as follows: January 14: Open nominations period February 25: Close of nominations period. Publication of list of nominated candidates IAB commences consideration of candidates On or before March 25: IAB selection delivered to IESG for confirmation On or before April 29: Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate Nominations --- Nominations (including self-nominations) should be sent to the IAB, [EMAIL PROTECTED] Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 2 to 3 Board meetings per year. The desirable characteristics of a candidate that are specific to the IETF's selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept as confidential to the IAB. Current IETF-Nominated Trustees --- The current IETF-Appointed ISOC Trustees and their term of appointment are: Fred Baker 2002 - 2005 (*) Margaret Wasserman 2003 - 2006 Eric Huizer 2004 - 2007 (*) Current term expires in 2005 Leslie Daigle, Chair, IAB ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Suggest no change: #739 Assuring ISOC commitment to AdminRest
On my re-reading of the thread, I think: . you are right that there wasn't substantive disagreement on the inclusion of the text: This BCP will take effect upon adoption of the BCP by the IESG and the concurrent insert thing that ISOC does which codifies in some interesting way the adoption of the relationship by ISOC . but I disagree that there was considerable support for filling the with by-law changes in ISOC. The filling of that seemed to have support (though, as you restated today, you don't agree with it) is the passing of a resolution to undertake the role outlined in the BCP. Speaking personally, I can live with inserting the text above, with a notion of passing a resolution in , though I think that the only thing that really counts at this juncture is getting on with making this a new operational IETF/ISOC relationship that works. (I.e., if the relationship does not work, no number of legal phrasings will help). That said, let me offer a few thoughts on why I specifically don't think a by-law change is what you want. The by-laws deal primarily in the mechanics of ISOCs structural implementation: who is a trustee, how many trustees it takes to do anything, etc. I know you would look to a lawyer to provide the specific wording, but I'm trying to grapple with what sort of a thing would be inserted here to meet your need: something that says ISOC will support the IETF per the structure outlined in BCPXX seems vastly out of place. What I really think you're looking at is the articles of incorporation, which spell out the purpose and reason for ISOC's existence and operation. Those already talk broadly of a mission of supporting Internet technology development. Broadly is the key word -- this is the generally specific sort of text that lawyers create when they know it's what the organization is going to be held to in order to defend such things as tax exempt status. The draft phrase I suggested above would not fit there; by the time a lawyer was done making it suitably generally specific, I don't think you'd be any more satisfied. So, why not a resolution, then? It's a formal record of an ISOC BoT having declared support for this activity, with the expectation of future ISOC BoTs adhering to the principle. Yes, a future ISOC BoT could adopt a resolution to change or nullify that support with little warning and less than a 4/5 majority vote. But, the truth of the matter is, if the ISOC BoT has gotten to the point where that seems like a reasonable course of action, we (the IETF, ISOC, the Internet at large) are in such deep doo-doo in our relationship that the action is not the bad news. All, of course, in my personal opinion. Leslie. Pete Resnick wrote: On 1/13/05 at 1:34 PM +0100, Harald Tveit Alvestrand wrote: I believe #739 is a matter that requires ISOC to form an opinion I agree; ISOC must suggest the mechanism by which they will agree to this partnership. it is not something that the IETF needs to come to consensus about, and it should not affect the text of the BCP. I completely disagree, and I think it is not at all bourne out by the discussion on the list. There was disagreement by some of us as to what specific mechanism ISOC should bring to bear on this (and I agreed with the proposal that ISOC should be solicited for that mechanism and the IETF should come to consensus on whether that mechanism was acceptable). However, I don't think there was any disagreement (including from Brian) that text needed to be added of the form: This BCP will take effect upon adoption of the BCP by the IESG and the concurrent insert thing that ISOC does which codifies in some interesting way the adoption of the relationship by ISOC The open (and I believe still open) argument is: As Brian Carpenter said: I'm not saying a bylaw change would be a bad thing, in due time. But ISOC can get a Board motion through in about 2 weeks, whereas a bylaw change takes several months. Making it a prerequisite would cause us to lose precious time. And the ISOC BoT has plenty of stuff on its plate just caring for the rest of the effects of this process, if I understand Steve Crocker correctly. I personally don't believe that a resolution is a sufficient mechanism for codification of this on the ISOC side. I made the suggestion of a by-law change, and I'm not convinced of the takes several months (though I'm willing to hear some convincing arguments as to why that should be the case). I'm willing to hear about other codifying mechanisms. I can't speak for others, but I suspect there are others in the same boat with me. I suggest that we close this ticket as no change required - the issue will not be forgotten, but it should not affect this document. I object to this entirely. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
