--On Tuesday, 25 July, 2006 12:08 -0700 Allison Mankin
<mankin(_at_)psg(_dot_)com> wrote:
Hi, Ray, and all,
I read the SOW earlier to check that it matched with the
draft-mankin-pub-req-10 (output of techspec), but I've now
given a read to other matters in the RFP.
If anyone wants to discuss points from this mail other than
those specifics to the RFP, I suppose we should do so on
independent(_at_)ietf(_dot_)org(_dot_)
1. Some wording under Independent Submissions is still a bit
confusing. 2.a. states the optional presentation of the
document to the IESG for end-run evaluation while it is in
the RFC Editor's initial review. 2.e states the mandatory
presentation which is called for by RFC 2026. 2.a says see
2.e. In a non-sequential reading, which is possible, 2.e
does not sound mandatory. But it is firmly required by RFC
2026.
[And while I have this topic: this is not because of power
projection for anyone, but because the WGs' labors are
heavily invested in RFCs as an end-product, and their
charters and work need to be consulted by their AD]
So I'd like to suggest that 2.e be changed a little bit:
OLD:
Submit document to IESG for review of
conflicts or confusion with IETF process, end runs around
working group activities, and obvious and significant
harm to the Internet
NEW:
As required by RFC 2026, submit document to IESG for
review of conflicts or confusion with IETF process, end
runs around working group activities, and obvious and
significant harm to the Internet
This change is counter to RFC 3932, which is claimed to have
removed "harm" from the things that the IESG will consider.
Reinstating that criterion in this RFP seems completely
inappropriate.
2.
g. Final Editing and Publication
1) Edit and publish as for IETF community documents
This publication process is not identical to IETF community
documents. IETF has a BCP (3932) which currently specifies
differences, but we're in some debate now (expressed during
the Thursday plenary in Montreal) about its full applicability
to the independent submissions. There should be some
statement in the SOW about how the differences, such as a
boilerplate stating the nature of the independent submissions,
or a specific type of identifier within the RFC series, will
be further resolved. How about wording like:
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 authorized by the
appropriate IETF community parties.
I agree there is a problem, but this appears to be the wrong
solution. See below.
h. Coordination with Other Document Streams
1) Coordination with and prioritization of other document
streams is the prerogative of the IAB
I'm assuming that h.1 is not intended to cover the document
differentiation issue, but in any event, it would not do it
well. The IESG and the BCP-approving community hasn't
finished discussing (by approving a changed BCP) a view that
the IAB is now arbiter of the IETF's public messaging on
independent RFCs.
Nor has the broader community agreed that the IESG (which is
more or less the same entity as the "BCP-approving community)
has the authority to do this.
Due to independent RFC's potential close
involvement with working group RFCs, there are reasons for WG
folks to really think about this. I don't think there's any
intention to affect a standards-related issue by placing
language in the RFP/contract, but we should really watch that
we do not.
The comments about focus in on an aspect of this situation that
has been extensively discussed in several forums recently and
that many of us had hoped to avoid confronting in the interest
of getting this RFP out. The current text pushes very close
to, if not past, the line that would require confronting the
issue; the text about definitely does.
To try to briefly summarize that issue, there are two theories
about the existence and role of the RFC Editor. One is that it
is a creature of the IETF (and/or IAB), to be redefined,
retasked, and reallocated at the whim of the IETF and its
management bodies. Whatever the IESG says the RFC Editor should
do, the RFC Editor must do. The other is that the RFC Editor
function existed long before there was an IETF and that, while
it is the traditional publisher of IETF-generated materials,
either party can change that relationship at any time (for
documents going forward -- the status of IETF-related documents
produced before a hypothetical changeover is ambiguous and the
IETF fairly clearly has no claim to Internet Standards produced
in the pre-IETF period).
While, again, I prefer that we not need to address the problem
now, I personally do not consider the first position sustainable
and believe it has implications that, if pressed to a
conclusion, will not make the IETF community happy.
As I have said many times before, it is my expectation that
whomever is acting as RFC Editor will try to do its work with
the best interests of the Internet Community as a major goal.
Doing so not only means agreeing to publish IETF documents as
long as the IETF wants that to happen, but working cooperatively
with the IETF and its leadership to avoid confusion among
documents produced in different ways but published under the
"RFC" label and, if necessary, to give IETF documents
appropriate priority. I believe it is reasonable to build that
expectation into the RFP and make it explicit.
But, if parts of this RFP evolve to assert that the RFC Editor
function is under IESG control for non-IETF documents, or that
the IESG can set rules for how non-IETF documents are handled
without the consent of the RFC Editor, then we have a problem.
In the most extreme version of that problem, the draft RFP is
complete nonsense: were I ISI, I would argue that 30-odd years
of publication history has turned "RFC Editor" into an
unregistered, but still established, trademark of ISI or USC
which IASA and ISOC not in a position to rebid or reallocate.
Being less reasonable than our colleagues at ISI, I would
probably take up a small collection, find myself a judge, and
seek an injunction against ISOC's issuing this thing.
I note in this context that IESG (or even IAB or IASA)
assertions about what they are in control of don't count for
much unless the RFC Editor agrees: I can stand on any street
corner, proclaim myself king of all I survey and start giving
people orders but, unless I can back it up with either legal
authority or an army, I'm much more likely to end up in
psychiatric care than widely recognized as sovereign. The fact
that, in the interest of the Internet community and perhaps of
continued funding from certain sources, the RFC Editor has, in
the past, decided to go along with such statements and posturing
does not imply blank-check agreement to do so in the future.
If we are to move forward without having to first resolve the
historical and control relationships, the RFP needs to be
respectful of the RFC Editor function and of the needs of the
Internet community outside the IETF. It needs to promote a
cooperative and mutually respectful relationship between the
IETF (and its leadership) and the RFC Editor, especially with
regard to documents that originate outside the IETF and that are
not processed through the IETF (other than via a mutually-agreed
IESG courtesy check for confusion and efforts to prevent
confusion of all forms). Or the RFP needs to go back for a
relatively comprehensive revision, starting with retitling it
to, perhaps, "IETF Publication Function Request for Proposal".
Perhaps the current RFC Editor organization would choose to
write a proposal to supply that function. I would hope that, if
the IASA decided to overconstrain how they handled independent
submissions, they would not do so, just as I would expect that
they would not submit a proposal against an RFP that required
IESG review and approval of ISI's research agenda to assure
consistency with IETF standards.
As part of the cooperative spirit and best interests of the
Internet attitude that I'm encouraging, I would assume that, if
a better arrangement could be found to perform the RFC Editor
function with compatible tasks and rules, ISI would be willing
to sign over any rights they have to the name, service, and
publication series. After all, the RFC Editor function didn't
originate there either. But, to the degree that this RFP, or
any other mechanism, proposes to change the historical
relationships and turn the RFC Editor function into something
that operates only as an IETF/IASA subcontractor, subject
exclusively to IASA management, I would expect --and hope-- that
they would be quite resistant to the idea.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf