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
On balance I don't think the 2026 reference is needed - we will say anyway
that IETF BCPs apply as relevant. And the "harm to the Internet"
clause is plain wrong - it isn't mentioned in 2026 and is excluded
explicitly by 3932.
Where will it say that IETF BCPs apply as relevant? Might RFC 2026
be construed as not relevant? IASA agreed to follow it, in my reading
of the formation of IASA.
As others thought, I just included the existing "harm to Internet"
blindly because it was there already. I think this should say then:
NEW NEW:
As required by RFC 2026, submit document to IESG for review of
conflicts or confusion with IETF process or working group activities.
The RFP and the contract can change in future if there is a BCP that
changes who in the IETF watches out for the *IETF's* representation in
the RFC series, but there are two BCPs which say that the IESG does
this now, and the RFC Editor currently needs to view this as a
mandatory check. RFC 3932 assures them of quick turnaround versus the
old system, because it does bar all but the conflict review.
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.
As was said, that is still an open discussion, so I don't think we
can specify it today.
I now see from the further discussion what some fault-lines are.
My concern is that "Edit and publish as for IETF community documents"
leaves open to the RFC Editor considerable latitude for how the independent
submissions appear in the broad community, for instance do they mimic
standards documents? Truth in advertising may need enforcement despite
best intentions. Jeffrey Hutzelman wrote well that:
However, contracts are about what happens when someone you thought
would act in good faith fails to do so.
Or perhaps, they are acting in good faith, but they are not effective -
who's to remedy if there's a problem by the editor and the authors slip
in specific effects [this could apply to the non-IETF streams in their own
ways too]. Effective delineations are needed.
In proposing the text above, I did not envision that IESG should
control the issue - IAB has the purview for RFC Editor, as stated
in RFC 2850 and other sources. But I didn't think till Leslie's mail
about IAB taking off their IETF hats so much when dealing with RFC Editor
matters (having both non-IETF hats and IETF hats, as I read it).
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.
[More explication: the authorizing party is TBD, but it is not specified
as "IETF community"; the RFC Editor gives input rather than being
self-defining.]
Allison
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf