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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

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

Tony



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]