Some comments: 2.1.4 - 6 months for the reserve is a funny number for an organization where the nominal income period is 4 months. Wouldn't it make more sense to spell out a reserve that covered a disaster case of a canceled meeting after the contracts had been signed? Something like: Also, in normal operating circumstances, the IASA would look to have a 6 month operating reserve for its non-meeting activities plus twice the recent average for meeting contract guarantees. 2.2 - IAOC openness While an annual face-to-face is a good idea, the normal IETF concept of openness is a public mail list. > ... IAB and IESG-appointed members of the IAOC are not subject > to recall by their appointing bodies. The placement of that statement at the end of the paragraph is really awkward and can be read to imply that those appointments are imune to recall. How about: In the event that an IAOC member abrogates his duties or acts against the bests interests of the IETF community, IAOC members are subject to recall. Any member, including those appointed by the IAB & IESG, may only be recalled using the recall procedure defined in RFC 3777. 2.3 Budget - > The specific timeline will be established each year, before the > second IETF meeting. Wouldn't it be cleaner to just specify that the budget process will be completed in the first half of the calendar year? That would be more consistent with the July 1 date in the outline and avoid the issue of the occasional mid-June meeting. If the goal was really to have it ready for the potnetial mid-June meeting, then make it 'first 5 months'. 3.4 > ... issuing RFPs and negotiating potential agreements with service providers. I don't think we can do that before we get the IAD on board. If we are hiring someone to do those tasks we should not only expect them to do the task, we should LET THEM do the task. I realize there is a desire to move quickly, but that step as written is probably counter productive. The more appropriate thing would be: ... documenting the expected deliverables for use in RFPs. 3.6 > o Technical infrastructure > > o Meeting management > > o Clerk's office > > o RFC Editor services to support IETF standards publication > > o IANA services to support IETF standards publication What about I-D editor??? > 4. Security Considerations > > This document describes a scenario for the structure of the IETF's > administrative support activities. It introduces no security > considerations for the Internet. Wouldn't failure of the administrative functions of the IETF adversly affect the overall security of the Internet? ;) > 5. IANA Considerations > > This document has no IANA considerations in the traditional sense. > As part of the extended IETF family, though, IANA may be interested > in the contents. > Doesn't it officially move the logical home of the IANA function along with the RFC Editor? If so I would think they would both be more than a little interested in the contents. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf