Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]