On Thu, 16 Jun 2005, Ted Hardie wrote:
There are two types of Information and Experimental documents; those
which are sponsored by an AD and those which come from the RFC Editor
to be checked for conflict with IETF work. In the latter case, you may
well see blank spaces, all no-objections, or similar. In the former case,
it might happen that something does not have a Yes because of something
like a Last Call comment to be resolved simultaneously with IESG review,
but it is unusual and considered as a "yes-->placeholder" collapsed.
Thank you for your explanation.
The IESG also asks different questions for the two tracks, because there
is a set of IESG Notes automatically added to RFC Editor-sponsored documents.
The review instructions for AD sponsored Informational and Experimentals is:
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
If I understand based on IESG notes, it appears you're unable to answer
the above question clearly. In particular that you say:
"As such these documents have not received full IETF review and
are published "AS-IS" to document the different approaches"
and:
"The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem"
The review instructions for RFC Editor-sponsored Informational and
Experimentals is:
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
So with RFC-Editor drafts, IESG is asked to evaluate the draft for
conflict with other standards and IETF work, but not necessarily
say that it agrees with it. That is good explanation, thank you.
Nevertheless it is unclear to me why the above points would in the
same way not apply to AD-sponsored drafts. If anything it would
indicate that as initial criteria for being "sponsored" the draft
would already have to have passed all above evaluation items and is
now being considered by IETF not just as individual contribution for
documentation of existing work but as something IETF is expected to
provide some kind of approval on (even if its just for experiment).
And overall (especially after reading your new note) the situation
seems to be that SPF & SID drafts can not find approval of IESG
so while they started as sponsored work, perhaps the situation right
now (with IESG note saying that you just want it documented) is
closer to the kind of documentation one would expect with draft being
submitted through RFC-Editor. So I think it maybe more appropriately
for IESG to directly reexamine evaluation criteria for the drafts and
work with them in the say way you would work as if it were drafts
coming from RFC-Editor.
Just to be clear, David Kessens proposed the note; there has been some
wordsmithing by others, but he was the person who brought it forward.
I believe David has some basic concerns about the usability of either
approach as well as concerns about using them in tandem.
The problem is not just using them "in tandem", using in tandem would mean
somebody doing both SPF and SID check on his/her system. The problem we
have is different in that both drafts attempt to rely on the same record
but use it differently, this is collision of namespaces for different
experiments and it does seem like its something that IESG should be
seriously concerned with.
I don't want to speak for David, but I think
these were not limited to the question of which identity is at issue.
Is it possible to ask David to come to this list and explain more about
his concerns?
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net