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

"Tony Hain" <> Fri, 24 September 2004 05:21 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA23063; Fri, 24 Sep 2004 01:21:23 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CAidF-0001n4-UE; Fri, 24 Sep 2004 01:28:34 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CAiTZ-0003u8-Do; Fri, 24 Sep 2004 01:18:33 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CAiSa-0003k8-4t for; Fri, 24 Sep 2004 01:17:32 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA22875 for <>; Fri, 24 Sep 2004 01:17:29 -0400 (EDT)
Message-Id: <>
Received: from ([] by with esmtp (Exim 4.33) id 1CAiZT-0001kA-Cb for; Fri, 24 Sep 2004 01:24:40 -0400
Received: from eaglet ( by with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <S6DA76> for <> from <>; Thu, 23 Sep 2004 22:20:26 -0700
From: Tony Hain <>
To: 'Margaret Wasserman' <>, 'Leslie Daigle' <>,
Date: Thu, 23 Sep 2004 22:17:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcShgmGwKIofTWFTQQ2C40T/96L7uwATLTpw
In-Reply-To: <p06020471bd789006d81a@[]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Content-Transfer-Encoding: 7bit
Subject: RE: Scenario O Re: Upcoming: further thoughts on where from here
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Content-Transfer-Encoding: 7bit

Margaret Wasserman wrote:
> >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.

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

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

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. 

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

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.

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

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

> 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

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

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

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. 

> The IANA structure is a bit more confusing to me, and I haven't yet
> 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.


Ietf mailing list