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.
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.
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.
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.
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.
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) <jhutz+@xxxxxxx> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf