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

[Margaret Wasserman <[e-mail]>]

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