Re: SPF and SenderID

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
[email protected]