I'm going to comment on Allison's original posting, since the target
is specific text changes to the RFP. (I have read the follow-ups).
Allison Mankin 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
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.
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.
As was said, that is still an open discussion, so I don't think we
can specify it today.
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. 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.
Indeed. On the other had, since the IAB has its oversight role, I don't see
the word 'prerogative' as out of place. It makes it clear in fact that
the prerogative *doesn't* belong to the source of funds.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf