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 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.
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.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???
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf