Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt

From: [email-masked]
Date: Tue, 24 Apr 2012 09:58:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Resolution of The SPF and Sender ID Experiments
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-spfbis-experiment-06.txt
	Pages           : 11
	Date            : 2012-04-24

   In 2006 the IETF published a suite of protocol documents comprising
   SPF and Sender ID, two proposed email authentication protocols.
   Because of possible interoperability issues, particularly but not
   only those created by simultaneous use of the two protocols by a
   receiver, the IESG was unable to determine technical consensus and
   decided it was best to publish all of RFC4405, RFC4406, RFC4407 and
   RFC4408 as Experimental documents.  The IESG invited the community to
   observe their deployments for a period of time, and expressed hope
   for later convergence of opinion.

   After six years, sufficient experience and evidence have been
   collected that the experiments thus created can be considered
   concluded.  This document presents those findings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Apr 2012 13:22:48 -0400

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the SPF Update Working Group of the IETF.
>

This version addresses all of my comments.  I note that Dave Crocker
made two substantive comments that I got directly, but that didn't
show up on the mailing list (he did CC the list, so I don't know why
they're not there).  In those, he said that the [DNS] reference should
also be normative, and I think he's right because of the discussion of
RR types.  Apart from that, my participant's opinion is that this
version is ready to ship.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Apr 2012 19:57:40 +0200

On Tue 24/Apr/2012 19:37:10 +0200 Barry Leiba wrote:
> 
> Apart from that, my participant's opinion is that this version is
> ready to ship.

May I ask how delivering this I-D affects the WG schedule?  The I-D is
scheduled for Aug 2012.  I like its findings and its conclusions, but
it still misses some data that may be relevant.  So, /if/ there's no
specific reason to ship it now, we could keep it dormant for a few
months and proceed as if it were shipped.  That way, that missing data
could have a chance, however remote.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 24 Apr 2012 10:59:53 -0700

Hi Barry,
>This version addresses all of my comments.  I note that Dave Crocker

Thanks for the review and for sending text.

>show up on the mailing list (he did CC the list, so I don't know why

Some of Dave Crocker's messages must have gone to the moderation 
queue as the email address was not subscribed to this mailing 
list.  I think that he cancelled the postings.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Apr 2012 11:17:24 -0700

On 4/24/2012 10:59 AM, S Moonesamy wrote:
>
> Some of Dave Crocker's messages must have gone to the moderation queue
> as the email address was not subscribed to this mailing list.  I think
> that he cancelled the postings.

I'm having some posting problems from some of my accounts.  They are 
persistent.

I didn't cancel the messages.

d/
-- 
  Dave Crocker
  bbiw.net

---

From: S Moonesamy <[email-masked]>
Date: Tue, 24 Apr 2012 11:30:46 -0700

Hi Dave,
>I didn't cancel the messages.

I saw the notices about messages posted from your current email 
address.  I didn't approve the messages as we had a conversation some 
time back about me approving the messages before you had the time to 
cancel them.  I am not sure whether that conversation was about this 
mailing list.

There are three messages, including the one you sent a few minutes 
ago, in the moderator queue.  I approved them and I'll approve other 
messages as usual.

If you still have problems posting to this mailing list, please let me know.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Apr 2012 11:44:09 -0700

On 4/24/2012 10:22 AM, Barry Leiba wrote:
>  I note that Dave Crocker
> RR types.

I've been having some mail-posting problems. For the record, here's what 
I sent...

-------- Original Message --------
Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05
Date: Sun, 22 Apr 2012 14:43:41 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Barry Leiba <[email-masked]>
CC: [email-masked] <[email-masked]>

On 4/22/2012 1:58 PM, Barry Leiba wrote:
> OLD
>     collected that the experiment thus created can be considered
>     concluded, and a single protocol can be advanced.  This document
>     presents those findings.
>
> I would prefer that this document avoid making pronouncements and
> stating these kinds of opinions ("a single protocol can be advanced").
>   The point of this draft is to document results.

+1

> OLD
>     Due to the absence of consensus behind one or the other, and because
>     Sender-ID supported use of the same policy statement defined by SPF,
>     the IESG at the time was concerned that an implementation of
>     Sender-ID might erroneously apply that statement to a message and,
>     depending on selected recipient actions, could improperly interfere
>     with message delivery.
>
> This seems to have a significant SPF bias.  May I suggest this?:

SPF defined the record.  It was there first.  Sender ID came afterwards,
creating the overload.  A 'bias' in this case has rather solid
historical precedent.

> NEW
>     Due to the absence of consensus behind one or the other and because
>     SPF and Sender-ID supported use of the same policy statement with
>     different semantics, the IESG at the time was concerned that
>     implementations of SPF or Sender-ID might erroneously apply a
>     statement that had been published with the semantics of the other,
>     and, depending on selected recipient actions, could improperly
>     interfere with message delivery.

My above comment notwithstanding, this wording looks fine to me, and in
general I concur with this sort of neutral language.

> OLD
>     It is important to note that this document makes no direct technical
>     comparison of the two protocols in terms of correctness, weaknesses,
>     or use case coverage.  The email community at large has already done
>     that.
>
> I suggest "has already done that through its deployment choices."
>   Otherwise, one might wonder where the comparison that's been done is
> documented.

ok.

> OLD
>     3.  Although the two mechanisms often used different email addresses
>         as the subject being evaluated, no data collected showed any
>         substantial operational benefit (e.g., cheaper processing,
>         improved accuracy) to using Sender-ID over SPF.
>
> I suggest "to using either mechanism over the other."

Hmmm.  Different issue:  Often the email addresses are the same.  It's
the /fields/ that are /always/ different.  I suggest changing the
wording to say "email address fields".

Tidbits of other cleanup:

      3.  Although the two mechanisms often use different email address
          fields for evaluation, no data collected showed any
          substantial operational benefit (e.g., cheaper processing,
          improved accuracy) to using one mechanism over the other..

> OLD
>     3.  The absence of significant adoption of the [SUBMITTER] extension,
>         [SENDER-ID], and [PRA], indicates that there is not a strong
>         community prepared to develop those mechanisms beyond
>         experimental status.
>
> I would MUCH rather see this reported factually, without further
> opinion.  Something like this:
>
> NEW
>     3.  The absence of significant adoption of the [SUBMITTER] extension,
>         [SENDER-ID], and [PRA], indicates that there is not a strong
>         community deploying and using these protocols.

Here, I think I disagree.  Part of the analysis can reasonably note that
the analysis period has gone a long time and that a failure to archive
much traction after this long is not likely to produce better traction
in the future.

> OLD
>     4.  Continued widespread use of [SPF] indicates it is worthy of
>         consideration for the Standards Track.
>
> I suggest this:
> NEW
>     4.  [SPF] has widespread implementation and deployment, comparable
>         to that of many Standards Track protocols.
>
> -- Security Considerations --
>
> OLD
>     This document contains information for the community, akin to an
>     implementation report, and does not introduce any new security
>     concerns.  Its implications could, in fact, resolve some.
>
> That last sentence seems odd.  Unless you want to be specific about it,
> I suggest removing it.

ok.

> -- Informative References --
>
> We can always argue whether an Informational document, by its nature,
> can have "normative" references.

There's nothing to argue about.  Many Informational documents are
specifications.  Specifications dictate behavior (within the context of
the specifications.) Some of the behaviors that are dictated
fundamentally rely on external specifications that are cited. Language
that dictates behavior is called 'normative'.  This includes such
essential citations.

I think this is a reasonable summary of the issue:

http://stackoverflow.com/questions/6420522/what-does-normative-and-non-normative-mean-in-reference-to-xml

I suspect the envisioned debate is caused by confusing normative-ness
with standards status...

>  Still, in the sense that we use it
> here, references that are central to the understanding of the document
> at hand are usually considered to be normative.  DNS is arguable, but
> I'd say no.  I think the references to PRA, SENDER-ID, SPF, and
> SUBMITTER are normative.

You think that SPF or Sender ID could function without the DNS
specification???  That is, what is it you think might be arguable about
classing it as a normative reference?

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Apr 2012 17:00:43 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, April 24, 2012 9:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group
> of the IETF.
> 
> [...]

Changes in this version:

- all of Barry's suggestions included

- clarify that only syntactically valid replies were included in the DNS numbers

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Tue, 24 Apr 2012 13:37:40 -0700

Hi Alessandro,
>scheduled for Aug 2012.  I like its findings and its conclusions, but

Producing a deliverable before its milestone is not a problem.  The 
Chairs have already commented that there is no reason the working 
group cannot be finished with its deliverables by the Fall.

>could have a chance, however remote.

A remote chance is like Internet dating.  I can safely say that 
Internet dating is out of scope. :-)

There should be at least a month before the IESG Evaluation.  Anyone 
who would like to find any missing data should keep that in mind.

Regards,
S. Moonesamy