On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
Yes, I understand, this only applies to the Independent Submission
stream.
We ask the IESG to review these documents, and that review is
technical.
I don't think it is appropriate for an editor to make a judgment of
whether
a technical note is, or is not appropriate to be included in a
document. I
think the presumption should be that it is appropriate, and the
authors have
a way to object. While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their
ability to
make judgments like whether the IESG note is appropriate or not.
I think it would be okay to have the note go through an IETF
consensus call.
+1 , including the "IETF consensus call" part.
(...and to venture into the water under the consensus bridge part of
the discussion...)
Joel wrote:
If I understand your note properly, your primary concern is that
folks will think that Independent submission are IETF products.
This is a fair concern.
But the same could be said all our experimental and informational
RFCs. Should we insist that all experimental and informational RFC,
even from IETF WGs, carry big warnings "THIS IS NOT AN IETF
STANDARD." Repeated multiple times to make sure folks do not miss it?
(remember, Independent Submissions are never standards track
documents.)
Wed try very hard to make it clear to folks that there is a
difference between standards track documents and non-standards track
documents. Independent Stream documents are not standards track
documents.
And we fail miserably in those cases too.
Since I first started contributing in the IETF, I have on countless
occasions had to explain to people who don't participate that some
given RFC is not a standard. To most of the world, RFC==standard.
Maybe putting "THIS IS NOT AN IETF STANDARD" all over the place would
help, but I'm not sure about even that. Even worse, I have personally
seen multiple instances of marketing people intentionally introducing
FUD by talking about compliancy to some non standards-track RFC. (or
even an ID that had been actively deprecated by the relevant working
group.) Personally, I think our first mistake was using the same
document name prefix for the different streams.
I am most particularly concerned about the case where a draft that was
presented to a work group that selected not to publish it, and then
later gets published in the independent stream.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf