Re: SPF and SenderID

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