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

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Sep 2004 11:09:46 -0400

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Sep 2004 11:54:44 -0400

--On Thursday, 23 September, 2004 11:09 -0400 Margaret Wasserman
<[email-masked]> wrote:

>...
> 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.
>...

Margaret, 

One of the weaknesses of both scenarios, IMO, is that the
position and job description for the IAD are a little
underspecified except in indirect ways.  However, when I go
through the proposals and review what is expected, especially in
the light of Tony's comments about sequencing (with which I
agree), I come up with an executive-level position that requires
a fair amount of executive-level management, planning, and
budgeting experience.  The "Scenario O" situation may make a
less strong requirement in those regards than the "Scenario C"
ones do, because the person would be working in an ISOC context
where some supplementary skills and advice may be readily
available (but I think we need to be careful about that, see
below), but, in neither case do we seem to be talking about a
position that would permit us to run an ad in a popular
publication or two and then make a quick choice among a group of
essentially equally appropriate people.  

If, instead, we really are talking about an executive-level
position that requires someone with considerable skills,
including being able to convince whomever makes the decision
that he or she is capable of working in the rather interesting
management/ reporting environments outlined in the Scenarios, a
period of two to three months (most of one of which is occupied
by the low-function holiday season in much of the US and Europe
(at least))between between "seat the IAOC" and "have the IAD
found, selected, negotiated with, hired, and sitting at a desk,
doing work" seems to me to be _wildly_ optimistic.   Based on
some experience, I rather suspect six working months would be
more realistic and we could easily not be that lucky.

Of course, this is not a basis on which to discriminate between
the two Scenarios; they both have versions of this excessive
optimism.  But it does impact the estimates of what should be
expected to be done in or by early 2005.

     john

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Sep 2004 22:17:14 -0700

Margaret Wasserman wrote:
...
> section a bit and remove the dates.

Having some firm (at least squishy) dates is probably a good idea. I was
just concerned that since our 'second meeting date' is highly variable
(mid-June to late Aug) we should really put a calendar oriented date on it.
It is also the case that our 'official work' occurs on the mail lists, so
the random date of a gathering should have nothing to do with an annual
process.

> anyway. When we originally made the timeline, I thought those events

I understand there is likely to be a lag, but any contracts prior to the IAD
being placed should be short-term/event based things that leave the hired
IAD in control of their own destiny. I can't imagine anyone we would want
accepting a position where their success/failure is measured on contracts
that were established prior to their hiring (particularly contracts
negotiated by admitted non-financial oriented technologists). 

In any case, since the IETF & IAOC are non-entities in legal terms we are
really talking about asking ISOC to act on our behalf for legal issues until
this gets settled. Given that, the whole section of text that talks about
the interim IAOC contracting activities should be reworked to make it
explicit that they are working in concert with ISOC to fulfill any necessary
short term contracts until the permanent IAD is placed. 

> where clean interfaces can usefully be inserted.

Well the I-D Editor is a fundamental cornerstone in our document process,
and therefore deserves to be explicit. Personally I don't have a problem
with moving the function to better align with the RFC Editor's office, and
if that is what you mean by 'leave it to IAOC' then fine, but I don't think
listing it as an explicit function preordains where it is carried out.

...
> documents are a bit vague in this area.

Well I was thinking about this from the traditional matrix management
perspective where the administrative entity is the 'home' no matter where
technical direction comes from. I agree the technical direction shouldn't
change. 

> relationship with the RFC Editor and IANA

And as discussed above the I-D Editor relationship with each of those should
be on the table.

> not for managing the RFC publication process.

In the overall scenario O world, RFC Editor is just one of the contract
modules. We would need to sort out with ISOC & the bodies that substantially
support the RFC Editor if that should be moved into the IETF Admin space, or
kept separate. That is not really something for the IETF to decide, other
than to be willing to take it on, and possibly make a recommendation about
the expected efficiency of doing so. 

> reached any well-formed conclusion about it.

I am sure most people will agree you could have stopped at 'a bit more
confusing'. ;)

In any case as things currently stand the most we can do is recommend a
relationship/inter-organization process between the I-D Editor/IANA/RFC
Editor. Given that they already have a working version of that I would
suggest that they provide the base text of what would make the most sense
going forward, and that can/should be independent from the scenario O text
as a recommendation to the IASA.

Tony

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 24 Sep 2004 11:06:32 -0400

On Thursday, September 23, 2004 22:17:14 -0700 Tony Hain 
<[email-masked]> wrote:

> if that is what you mean by 'leave it to IAOC' then fine, but I don't
> think listing it as an explicit function preordains where it is carried
> out.

Actually, in our current process there is no such thing as an I-D Editor.
The RFC actually _edits_ documents, massaging them into the consistent form 
you see published in the RFC archive, making sure that the IANA's needs are 
met, etc.  I'd guess they also check spelling, grammar, usage, etc.

No one does those things for I-D's, and we don't want anyone to do those 
things for I-D's.  I guess I personally wish there would be a bit more 
checking that basic guidelines like "no non-ASCII characters" and "lines 
must be 70 characters long, not 500" were met, and hopefully an automated 
system (if it happens) will do that.

But really, operating the I-D repository is either part of the clerk 
function or part of the technical infrastructure function.  IMHO it has 
insufficient substance to be treated separately from these.

> technical direction comes from. I agree the technical direction shouldn't

I expect that for the foreseeable future, the only thing about the IANA 
function that would change is the legal framework surrounding it.  Instead 
of performing the operation under an MoU, ICANN would do so under a 
contract with whatever sort of supporting organization we end up with.

So I don't think there's an "IANA Consideration" per se, in that nothing in 
this proposal affects the operation of the IANA by doing things like making 
registrations or creating new registries.

Of course it is expected and desired that we'll get input from RFC-Editor, 
IANA, ICANN, the iSoc BoT, etc etc etc.

> modules. We would need to sort out with ISOC & the bodies that
> substantially support the RFC Editor if that should be moved into the
> IETF Admin space, or kept separate. That is not really something for the
> IETF to decide, other than to be willing to take it on, and possibly make
> a recommendation about the expected efficiency of doing so.

I think Margaret's characterization is fairly accurate.  Under the present 
process, the RFC-Editor is a semi-independent entity which may, completely 
at its own discretion, accept and publish documents which have never 
touched the IETF process.  It's expected that they will normally request 
and receive IESG advice on such publication, but they are not required to 
ask for advice or to follow the IESG's recommendation.

Under that model, while ISOC provides some (all?) funding for the 
RFC-Editor function, and the RFC-Editor mostly publishes IETF documents, 
it's not at all clear to me that we, ISOC, or any proposed supporting 
organization would get to decide who performs that function.  So I'm not 
sure it is "just one of the contract modules".

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA