On 2007-03-05 21:15, Jari Arkko wrote:
John, Bob -- I agree with you but I have difficulties in coming
up with exact rules, and I'd rather not have a very hard rule
anyway since ultimately its a judgment call whether the
document has really been in the IETF process. So unless
you have some specific text suggestion that we could look
at, I don't know what else we could write.
I do think, however, that with the "should normally" it is
very clear for the authors where to seek publication
first.
I agree. Since ultimately the publish decision is a judgement call,
I think it is very hard to write more precise text.
Brian
Jari
John C Klensin kirjoitti:
--On Monday, 05 March, 2007 09:31 -0800 Bob Braden
<[EMAIL PROTECTED]> wrote:
*> OLD:
*> o Documents considered by IETF Working Groups but not
standardized. *> While many documents of this type are
published via the IESG *> approval path (see RFC 3932,
Section 1 [RFC3932]), the independent *> submission
...
NEW:
*> o Documents considered by IETF Working Groups but not
standardized. *> While many documents of this type
are still published in the IETF *> document stream
[RFC2026,draft-iesg-sponsoring-guidelines] as *>
Informational or Experimental RFCs, the independent submission
*> path has traditionally been open to them as well.
However, because *> of their intimate connection to
the IETF Standards Process *> and WG activites and
the consequent sensitivity to exact *> statements of
*> relationships and to timing, there is reason to
believe that such *> documents should normally be
published via the IETF stream. In *> any event, these
documents are published for the historical record. *>
This is an issue that arises often in practice, so we need to
be very clear about what we mean. What do we mean by
"considered", and exactly what question does the RFC Editor
need to ask an author to find out if a new independent
submission has been tainted forever by being "considered" by
some working group?
I agree with Bob that we have a delicate issue here and that we
should be careful to avoid text that locks us into a place where
we don't want to be.
I believe that it is essential to the independent submission
process and to the community that the RFC Editor be able to
publish documents that the IESG and/or some IETF WG doesn't like
even after they have "considered" them. I believe that such
documents should be held to a very high standard for clarity of
role in order to be published as independent submissions, but
that it is important that it be possible for an author and the
RFC Editor to respond to an IESG comment equivalent to "The
foobar WG looked at this and considered it A Bad Idea, so Do Not
Publish" by revising the document to make the differences of
opinion clear and then publishing it as a dissent.
I think that a document that is developed by a WG, or developed
as input to a WG, should go to the IESG for sponsorship first,
both as a "right of first refusal" basis and as a matter of
efficiency. But, if the ADs decline to sponsor the document,
and it is clear from the text that it is not an IETF
standards-track document or a candidate for such standardization
(and, ideally, why), nothing should prevent its submission and
processing on the "independent" path.
I don't have a strong opinion as to whether "should normally" in
the proposed text above is sufficient to cover those cases, but
I suspect that we should attempt to be little bit more clear.
john
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
