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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf