On Sun, 19 Mar 2006, Keith Moore wrote:
I will however caution against the assumption that IESG is inherently
overbearing and a separate review function is inherently more
reasonable. No matter who does the review there will always be the
potential for capriciousness on the part of the reviewer.
It seems to me that while many prefer IESG review some believe it may not
always be fair and balanced.
Again, this will be true no matter who does the review.
True. But if you want to make RFC-Editor a separate function from
IETF/IESG you must allow it choices on who would do a review
So if I can make a suggestion, it would be
good while defaulting to IESG review to also specify that submitter may
challenge their review results and/or request an independent review from
another source.
That sounds like an appeals process to me.
Both appeals process and process where submitter if he thinks IETF is not
fair in its reviews can request independent review in the first place
(though IESG would still need to provide its review as to if there are
any conflicts and may choose to provide additional technical review as
additional input as well). The point being that technical reviews do not
have to come exclusively from IESG and that rfc-editor should have access
to multiple inputs deciding if publication is appropriate.
It's not at all clear to me
that we can afford the resources to give the privilege of appeal to
mere individuals.
Excuse me? What do you think IETF is or do you really prefer to see
it officially turn into IVTF?
Also it seems that not specifying how long review should take allows to
delay document indefinitely
That's a bit like saying that an SMTP server should not be able to
delay mail indefinitely no matter how much SPAM it gets.
It should not. If server is loaded with processing existing email, it
should not delay processing longer and longer internally but directly
start answering with 400 error. To turn this analogy (which I don't
think is very good in the first place) to publication process - RFC
editor can say that its overloaded and will not accept submissions
in the first place, but if it accepted submission - there should be
finite time in which it should be delayed within IESG review stage.
There are a near-infinite number of simians with keyboards, while IETF
review resources are (and always will be) finite and precious. So no
matter who does the review for individual submissions, I think that
it's perfectly reasonable for that reviewer to be able to say "Sorry,
we receive too many invididual submissions to review them all, and yours
doesn't pass the smell test.
No smell tests please just because you're overworked and don't have time
for substantial review. Either all submissions are rejected due to load
or none.
RFC-Editor can report to ISOC and IETF if it begins to experience too
high a load with individual reviews and request additional funding or
input to improve its process to deal with this. However if I understand
current situation, the individual publications requests directly to RFC
Editor have not been anything close to serious issue and its IETF's own
documents that require IESG review that put greatest stress on IESG
workload and delays in RFC publication.
You may wish to seek publication through other channels". This is no
different than any other publisher. IETF is not a vanity press.
The question here is about RFC Editor and its process. Original function
of RFCs after all was to document internet protocols and how to use them
to allow others to know what each protocol is about from common easily
searchable source. IETF on the other hand is organization responsible with
engineering standards for certain internet functions - that means it goes
quite a bit further then just publication or approval of documents but
actually is engaged in group effort to engineer the service/protocol where
the need for such functionality exists.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf