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

On Thursday, September 23, 2004 22:17:14 -0700 Tony Hain 
<alh-ietf(_at_)tndh(_dot_)net> wrote:
> 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+(_at_)cmu(_dot_)edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf