If we really feel that the current approach does not make non-standards
clear enough, then we should address that for all experimental or
informational documents. It is basically unrelated to the Independent
Stream issue.
With regard to documents that are alternatives to existing IETF work,
the RFC Editor has always required, as is appropriate for any academic
work, a description of the relationship to existing work. Reviewers who
know the area and work are selected. Thus, the document, in its text,
is expected to explain why it is different from the standard. Which
also requires it to be clear that it is different from the standard.
Handling such discrepancies in the document is both clearer, more
effective, and fairer to the authors than trying to solve the problem by
slapping a note on the front of the document.
And before someone says "but the ISE is not requrie to do that", note
that the ISE is required to maintain the quality of the stream. That
includes ensuring that there is suitable description of the relationship
to existing work. So not only is this the current practice, but it is
part of what we can reasonably expect.
I guess this relates to a lot of my problem with this whole "mandatory
IESG notes" approach. If there is a real problem with the document,
then the document should address the problem. If the IESG does not like
the light the document puts the IETF into, then we probably made a
mistake earlier, and this is not the place to fix it.
And given that these are Independent Submissions, they aren't supposed
to be subject to community review.
Yours,
Joel
Ben Campbell wrote:
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf