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