Hi Tony,
Great feedback. Thanks! A few comments in-line:
At 1:08 AM -0700 9/23/04, Tony Hain wrote:
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.
I had been thinking that the IAOC will probably choose to get event insurance to cover cancellation of an IETF meeting due to outside forces (airline strike, earthquake, etc.).
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.
True. IAOC financial reports and discussions should happen on open lists. We should probably also add a requirement that minutes from IAOC meetings/calls be publicly available.
... 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.
Yes, your text is much better. We should also make it clear whether or not ISOC can recall its appointed member... I just realized that's missing from this paragraph, but I think the same rules should apply (chosen by ISOC but not a representative, RFC 3777 recall only).
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'.
Maybe the wording could use some tuning, or we could up-level this section a bit and remove the dates.
3.4... issuing RFPs and negotiating potential agreements with serviceproviders.
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.
Given that the schedule has the interim IAOC formed in November and the IAD hired in January, I think that this may be reasonable. The interim IAOC would be hard put to organize themselves and get together a detailed description of the deliverables in two months, anyway. When we originally made the timeline, I thought those events would be further apart.
3.6o 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???
I think that is currently included in the "clerk's office". Anyway, I think it should be the IAOC's job to figure out what we need and where clean interfaces can usefully be inserted.
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.
By my interpretation of RFC 3716 and Scenarios O & C, the homes of IANA and the RFC Editor wouldn't change. The IAD would be responsible for handling the IETF's relationships (contracts, MOUs, whatever) with the RFC Editor and IANA, but the IASA would not be responsible for the technical/standards process work of these groups. Other interpretations are possible, though, because all of these documents are a bit vague in this area.
Independent of deciding which scenario we want to pursue, I think that we will need to have some discussion about the IETF's relationship with the RFC Editor and IANA.
Personally, I currently see the RFC Editor as a separate and independent entity from the IETF, one with whom we have a cooperative and mutually beneficial agreement regarding IETF standards editing and publication. So, I think that the IETF administrative support group (be it IASA or IASF) could/should only be responsible for handling the IETF end of that agreement (contract, MOU, whatever), not for managing the RFC publication process.
The IANA structure is a bit more confusing to me, and I haven't yet reached any well-formed conclusion about it.
Margaret
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf