At 12:47 PM -0700 6/16/05, william(at)elan.net wrote:
On Thu, 16 Jun 2005, Ted Hardie wrote:
A sponsoring AD always has a ballot position of YES when they bring
a document to the IESG.
I don't think it is always. I will check datatracker more but I've
definitely seen no objections from everyone including sponsoring AD
for some documents (especially individual submissions for information
or experimental track).
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.
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?"
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.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.
As was documented on the IETF list response to Wayne, there was no
support for at this time for publishing the spf draft as a Proposed
Standard (to be clear: the IESG was asked this question at a
telechat, and no AD thought it was appropriate).
Could you be more specific on which day this telechat happened and if
the logs/brief summary for it are available?
It was the June 9th telechat; the minutes get approved at the following
telechat (a week from today), and they'll be public then. The response
to Wayne contains all the data, though: the IESG considered it, but did
not find support for it.
The IESG is currently considering moving forward on the basis of an IESG note
suggested by David Kessens. Once the IESG agrees that the document set
is ready, the sponsoring AD position will go back to YES.
...
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
I'd appreciate if you discussed more rational that went behind your note
and its text. I do understand that IETF does not wish to take position on
if authenticating PRA or MAILFROM identities is better choice for email.
This is not new and its one of the reason that MARID probably failed as
such decision may not have been something that we could easily find
consensus on. But it seems to me taking not position on above is
different then the note that you propose to add to the drafts.
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. I don't want to speak for David, but I think
these were not limited to the question of which identity is at issue.
Also it appears to me the IESG criteria for when evaluating
documents (especially for experimental status) is not necessarily to
see if certain approach is good or bad for internet future but more
importantly to make sure that proposal would not directly create
problems for something else being done at IETF and most important to
make sure that the proposal does not cause people to violate
existing standards. So is my understanding about this being part of
IESG evaluation wrong?
See above for the evaluation instructions.
regards,
Ted Hardie