todd glassey wrote:
So let me ask the obvious thing... why is the RFP content being voted on?
This is a business decision in regard to services and process. Why is any of
it open to review inside the IETF?
Because the lunatics want to run the asylum? ;-)
Seriously though, it seems to me that most people agree
with us, and want to let the IAD and IESG do their jobs,
and stop all this obsessing over every detail of our "Process".
How about if we get that "quality" and "timeliness" thing
under control before spending a lot of time agreeing on
the 427 most important factors in selecting IETF meeting locations?
(Just my $0.02. OK, maybe it's the whole dollar :-)
Todd
Andy
----- Original Message -----
From: "John C Klensin" <john-ietf@xxxxxxx>
To: "Ted Hardie" <hardie@xxxxxxxxxxxx>; "Jeffrey Hutzelman" <jhutz@xxxxxxx>;
"Allison Mankin" <mankin@xxxxxxx>; "IETF Administrative Director"
<iad@xxxxxxxx>
Cc: <iaoc@xxxxxxxx>; <ietf@xxxxxxxx>
Sent: Wednesday, July 26, 2006 2:56 PM
Subject: Re: RFC Editor RFP Review Request
--On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie
<hardie@xxxxxxxxxxxx> wrote:
At 3:28 PM -0400 7/26/06, John C Klensin wrote:
The other is that, to some readers, it appears to impose
binding requirements on how the RFC Editor deals with input
from the IESG, either directly (as in "if we recommend that
this text be inserted, you must insert it or not publish") or
indirectly (as in "if you don't follow our recommendations,
we will see to it that your funding is cut off"). For those
of us who believe that it is important to the Internet that
the RFC Editor function as an independent, cooperating,
entity rather than as a subsidiary of the IETF, that level of
requirement is not acceptable (that consideration is the
source of this discussion about aspects of the RFP and what
should, or should not, be in it). While the IETF can attempt
to establish links to particular funding sources and apply
leverage that way (which some of us are trying to
discourage), it is also beyond the ability of the IETF to
give itself the authority to impose such requirements
directly, any more than approval of a document as an IETF
Standard can force someone to conform to it.
I don't agree with this understanding, but I appreciate your
taking the time to clarify it. The "imposition of binding
requirements" you cite above is, from my way of looking at it,
instead a description of how the two cooperating entities
cooperate. Putting descriptions of that kind into the RFP
(or, rather, references to them) is useful for a potential
respondent so that know what timelines and level of external,
unpaid effort to expect from the IETF. Other ways around this
seem to have their own headaches. For example, requiring the
publisher of the independent stream to establish that a
document does not inappropriately usurp an unregistered
standards-dependent IANA namespace or reserved protocol
bits would otherwise take the time and talents of the
publisher's review teams. That slows the stream or increases
costs in a different way.
Then I think we are more or less on the same page. The
challenge now is to get the RFP to appropriately reflect that
shared understanding.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf