RE: Scenario O Re: Upcoming: further thoughts on where from here

["Tony Hain" <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf