--On Thursday, 27 July, 2006 14:40 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
> ...
>>> My main object is for the RFP to say to a prospective RFC
>>> Editor that the delineation of the independent submission
>>> series will be under the contract holder's management in
>>> some way, allowing input from the editor. I want to urge
>>> this just because the RFC series is shared by four streams.
>>> In justifying this before, I've talked mainly about the IETF
>>> stream because it is the one I know the best, but I could
>>> also detail taking this care for the others. Anyway, here's
>>> a revised proposal for the text:
>>>
>>> NEW NEW:
>>> 1) Edit and publish with the same steps as IETF
>>> community documents but with clear indications that
>>> these belong to an independent series. Specifics of
>>> these indications will be developed and authorized
>>> by an appropriate party to be determined, with input
>>> from the RFC Editor.
>>
>>
>> Since I have found myself in the uncomfortable position of
>> being temporary spokesperson for those whose views are
>> somewhat more conservative than mine, let me suggest, as a
>> clarification what this would look like if done from a more
>> traditional view (please see many earlier comments to clarify
>> the use of "conservative" and "traditional"):
>>
>> ... When documents are published at the request of the
>> IETF community, including for this purpose the IAB and
>> IRTF, include clear indications about the status and
>> origin of these documents. Develop appropriate
>> indications in conjunction with the requesting bodies...
>
> It's my opinion that we should stay silent on this matter in
> the
> RFP. It really won't be a crucial issue in analyzing the bids,
> and we have time to work out the words before negotiating the
> final
> SOW.
>
> I think I would argue for symmetry (i.e. John's words are fine
> for
> the I* streams but I'd like to see something equivalent for the
> Independent stream).
>
>> Explanation:
>
> I agree with all these points. I believe the RFP text is
> compatible
> with them.
Brian,
I hope you are right. However, I see one condition on which the
RFC must reflect the nature of decisions about these questions.
Suppose we had two groups of entities that might logically
respond to the RFP.
One group, for whatever current or historical reasons, is
strongly committed to the independent submission model, perhaps
even with Joe's definition of "independent" (which I personally
sympathize with but consider a little extreme--see separate,
forthcoming, note). The role they are interested in involves an
RFC Editor-like function that is somewhat independent of the
IETF although willing to publish IETF-produced specifications
more or less as required by the IETF. If that is not the
definition of the role, they might lose interest in the
IASA-specified job, instead deciding to try to establish a
publication series that focused on documents and pieces that
serve the networking community, perhaps at the boundary between
research and ready-to-deploy specifications, but not moving into
standards.
The second group might, hypothetically, care less about these
issues and be more interested in a "whatever the IETF wants"
editing/ publishing job, which might or might not include an
IESG-supervised "independent" thread.
I don't need to take a position here on which of those
approaches would be better for the IETF or the broader
community. But, if groups aligned with the different approaches
exist, then it seems to me that we have two problems that the
RFP cannot plausibly avoid:
(1) An RFP aligned with "the IETF leadership is in control of
everything" is not going to get a response (or at least should
not get a response) from members of the first group. They
can't very well respond within the terms of such an RFP and hope
to renegotiate the relationship later. That would also
constitute use of language in the RFP to determine who can
plausibly bid. That is something the IASA can clearly do, but
it probably isn't wise, especially if there really is support
for an independent process in the IETF community.
(2) If the first group then goes off and identifies funding and
an institutional home for that non-standards-publication
mission, they might have a legitimate historical claim to
calling the documents they produce "RFCs" and even continuing
RFC numbering from whatever the last number was as of the end of
December (or whenever the current arrangements terminate). At
that point, if the IETF continues to use the "RFC" terminology
and its own, divergent, series numbering, we have, at best,
massive confusion which, whatever its other properties, does not
serve the Internet community well. Of course, there is also the
possibility of either that first group and institutional sponsor
or the IASA, deciding that the confusion level is high enough
that they needed to seek a legal determination about rights to
the "RFC" terminology. Whatever the outcome of that process,
the one thing that can be guaranteed is that the community loses.
I believe we need to invest some serious effort in avoiding
those scenarios, not just hoping that the RFP can be issued
while ignoring them and the possibility of their arising.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf