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

From: [email-masked]
Date: Wed, 18 Apr 2012 11:58:30 -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/Sender-ID Experiment
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-spfbis-experiment-04.txt
	Pages           : 10
	Date            : 2012-04-18

   In 2006 the IETF published a suite of protocol documents comprising
   SPF and Sender-ID, two proposed email authentication protocols.
   Because of interoperability concerns created by simultaneous use of
   the two protocols by a receiver, and some concerns with Sender-ID and
   compatibility with existing standards, the IESG required them to have
   Experimental status and invited the community to observe their
   deployments for a period of time, hoping convergence would be
   possible later.

   After six years, sufficient experience and evidence have been
   collected that the experiment thus created can be considered
   concluded, and a single protocol can be advanced.  This memo presents
   those findings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-04.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-04.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Apr 2012 19:03:35 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, April 18, 2012 11:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-spfbis-experiment-04.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:

- present DNS reports in tabular format, suggested by John Leslie

- reorganize "analysis" and "conclusions" into their own top-level sections

- rewrite conclusions so they don't sound/look like IESG instructions

- corrections and suggestions from Scott Kitterman

- update TDP survey numbers

- remove text that speculates on the "why" part of the outcome, and some other non-neutral text

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 15:09:58 -0400

On Wednesday, April 18, 2012 11:58:30 AM [email-masked] wrote:
> directories. This draft is a work item of the SPF Update Working Group of
> the IETF.
> 

Ship It!

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 18 Apr 2012 13:52:36 -0600

Murray,

Looks good.

Alan M.

On 4/18/2012 1:03 PM, Murray S. Kucherawy wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Apr 2012 15:53:52 -0400

Other than the following two comments, this report draft appears to 
acceptable.

The following are related:

In section 5, item 2, I continue to believe the use of "de facto" 
obsolete is incorrectly applied (because its not true) and wish 
another technical term can used - perhaps - LOW USAGE.

    - By using "de facto obsolete" it implies that VENDORS have activated
      deprecated or stop using it, or removed it as an option for 
operators.
      I don't see any evidence of that nor do I believe its true because
      that will also means they don't no longer care about the high 
corporate
      branding value the term "Sender ID" had, despite the fact that 
in reality
      it was piggy backing on SPF.  That is what Meng Wong wanted - 
the Corporate
      Branding and Sponsorship of Microsoft "Sender ID" benefiting SPF 
world wide
      adoption.  He told me so directly when I asked why did he allow 
MS get
      the sole patent disclosure credit without any prior art 
mentioning of
      SPF or himself.  So please do not underestimate how serious this
      "de facto obsolete" has or in fact will be ignored, or even make 
this
      report less trustworthy to accept as a whole.  In other words, why
      even go there when you don't need to?

Related In section 3, it must be emphasize that it was ALWAYS expected 
that the SIDF and SPF v1.0 domains will match and the SIDF only 
covered certain use cases that was certainly LESS than the majority. 
The reports says "at least 50% of the time," I may suggest to change 
the to

        "at least 50% and has high as over 80% of the time"

but regardless if its 50, 80, or 95%, the point remains - it was 
always expected to be a LOW VOLUME (when they did not match) and the 
empirical data showing the high equality is evidence confirmation of 
the original design expectation.

So if anything, I would suggest that this section or else where make 
light of that protocol expectation for PRA.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 16:03:32 -0400

>       even go there when you don't need to?

This is not about branding, so I think your related comments are off topic.  
This is  a technical forum.  I also think that whatever Meng Wong may have 
wanted when he agreed to the SPF/Caller ID For Email merger for MARID, it's 
equally irrelevant.  None of these documents are products of that working 
group.

Personally I prefer we just say that they should not be advanced onto 
standards track as that's all we need to do to finish the experiment, but I 
don't think branding has any place in the discussion.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Apr 2012 16:25:02 -0400

Scott Kitterman wrote:
>>  By using "de facto obsolete" it implies that VENDORS have activated
>>  operators. I don't see any evidence of that nor do I believe its true because
>>  corporate branding value the term "Sender ID" had, despite the fact 
>>  that in reality it was piggy backing on SPF.  That is what Meng Wong 
>>  wanted - the Corporate Branding and Sponsorship of Microsoft "Sender ID" 
>>  benefiting SPF world wide adoption.  He told me so directly when I asked 
>>  why did he allow MS get the sole patent disclosure credit without 
>>  any prior art  mentioning of SPF or himself.  So please do not 
>>  underestimate how serious this "de facto obsolete" has or in fact 
>>  will be ignored, or even make this report less trustworthy to accept 
>>  as a whole.  In other words, why even go there when you don't need to?
> 

I was never seeking to be discussed - its should of been a natural 
consideration overall engineering mindset, because at the end of the 
day, the technical outcome of what is essentially a "Product Update" 
will have an impact on the production (where markeing and branding 
exist) side, or maybe not depending if its viewed with non-convincing, 
bias justifications with it product impacting conclusions.

Thats just reality Scott, its like saying that all of sudden 
everyone's documenations and web site will be expected to remove all 
their "branding" using Sender ID as the technology in play even 
thought between you, me and that gatepost, we know its all about SPF. 
  How about technology promotion sites citing large groups of 
"Corporate Brand" vendors support, like:

http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx

Nonetheless, the branding comment was a sub-note. the real issue is 
that is not true, de facto obsolete is not correct for the other 
reasons stated. Do you disagree it was never expected to be a high 
volume?  That PRA was only be a low percentage of use cases?   You 
can't use this confirmed observation to suggest it was low usage, 
therefore by "de facto" obsolete.

It isn't correct.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 16:43:35 -0400

On Wednesday, April 18, 2012 04:25:02 PM Hector Santos wrote:
> >>  operators. I don't see any evidence of that nor do I believe its true
> >>  because that will also means they don't no longer care about the high

I'm trying to stay out of the how you measure it discussion.  I think it's 
clear where the industry momentum is and I'm not concerned about if we're 
getting it wrong.  As I said, I'd prefer "do not advance" over "defacto 
obsolete", but I don't think it makes a lot of difference.

Vendors are free to support obsolete protocols as long as they care to and do 
(witness how long it's taking to get rid of SSL V2).  That's a separate 
discussion.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Apr 2012 21:33:53 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, April 18, 2012 1:44 PM
> To: [email-masked]
> Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt
> 
> I'm trying to stay out of the how you measure it discussion.  I think
> it's clear where the industry momentum is and I'm not concerned about
> if we're getting it wrong.  As I said, I'd prefer "do not advance" over
> "defacto obsolete", but I don't think it makes a lot of difference.

The Sender-ID suite positioned itself to handle the 20% of cases that SPF got "wrong" (namely stuff like forwarding).  That's not the same as saying it would only get used 20% of the time, because that then means its intended use was as a fallback mechanism only evaluated when SPF didn't say "pass", and I don't see that in any documentation anywhere.  So I claim the cited premise is incorrect.

In 2006 when these things were rolled out, there was an industry push for Sender-ID adoption.  It has faded to less than 5%, as multiple surveys have now demonstrated.  That is the very dictionary definition of "de facto obsolete".

"Low usage in favor of something else, as shown by these surveys" is just a long-winded way of saying "de facto obsolete".

> Vendors are free to support obsolete protocols as long as they care to
> and do (witness how long it's taking to get rid of SSL V2).  That's a
> separate discussion.

Right, and I don't think we need to be concerned with marketing or branding either.  That's for a community separate from this one.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Apr 2012 19:37:31 -0400

Hi,

In the interest of moving forward, I will accept the report but I will 
make a recorded objection during LC regarding the specific "de facto 
obsolete" points I made.

Thanks for your consideration of my report inputs, your work effort is 
admirable and appreciated.

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Apr 2012 20:08:30 -0400

Scott Kitterman wrote:

> I'm trying to stay out of the how you measure it discussion. 

But you're not. :)  We are all measuring it at some level and when you 
(speaking in general) use terms like Wide Deployment, Widespread, 
Large Scale or throw out data points like 5%, low usage and "de factor 
Obsolete", etc, you are inherently using Big Wheel,  "Branding", Who's 
Who using What matters most concepts and overall the old General 
Motors corporate mantra of "What's good for GM, is good for America!" :)

> I think it's clear where the industry momentum is..

Case in point! :)

> and I'm not concerned about if we're getting it wrong.  

Maybe there is a reason for that I am not catching, but I do admit I 
have always been cursed with corporate QA methodology:

     "Getting it right... the first time!"

Its not about perfection, but doing your best to avoid the obvious 
that in the end don't require you to redo, repeat or revisit something 
that could of avoided in the first place, especially when it was known 
upfront but some reason was ignored or thrown aside.  Doing it right, 
the first time is about producing results with higher customer 
satisfaction and minimizing cost across the aboard.

> (witness how long it's taking to get rid of SSL V2).  That's a separate 

Well, I personally believe that when the all issues are considered, 
better decisions are made that doesn't or lowers the need to revisit 
it latter.  With this specific "de facto obsolete", in my view will 
have a ripple effort, and quite frankly will trouble the people who 
are using it, even they are just among the so called "5%" as its 
claimed to be.

Just consider, the SPF web site will be among the first to HIGHLIGHT 
in whatever fashion or words, SENDER-ID was DEAD and officially 
disclaimed OBSOLETE by the IETF and no longer something any domain 
should to think about or bother with.  I doubt the web site will be 
able to resist it. Thats all part of marketing and branding! :)

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 20:47:09 -0400

> Motors corporate mantra of "What's good for GM, is good for America!" :)

I said I was trying to stay out of it.  I wasn't speaking in general.  I was 
speaking specifically.  I'm mostly interested in reviewing the draft to make 
sure it doesn't mis-state the history.  Writing it is a hard problem and I'm 
glad it's not me doing it.

> > I think it's clear where the industry momentum is..

That is my opinion.  I don't think it would be reasonable to put that in the 
draft, so I'm not sure what it's a case in point of.

> have always been cursed with corporate QA methodology:

Because I'm confident the basic thrust is right.

> satisfaction and minimizing cost across the aboard.

If the IETF had done this in this area with that in mind, then it would have 
been approached very differently in my opinion.

> > Vendors are free to support obsolete protocols as long as they care to and
> > do (witness how long it's taking to get rid of SSL V2).  That's a
> > separate discussion.
> 

It won't even try.  It'll probably be me that writes the text.

In this working group we need to stay focused on the technical aspects of the 
problem.  In the broader sense there are lots of opinions and perspectives, 
but they don't help here.  I don't think any of the points about marketing are 
relevant to the chartered work of the group.

I also don't think it matters much in the end if the draft says "de facto 
obsolete" or "should not be advanced" or anything other than "standards track" 
for Sender ID.  The result will be roughly the same SPF is advanced in this 
working group and Sender ID is not.  People will draw logical conclusions from 
that independent of the precise words in the draft, so I'd encourage you to 
not get too wrapped up in the exact wording.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Apr 2012 21:41:30 -0400

> been approached very differently in my opinion.

Well, I think it has for the most part. But in my opinion, its been 
different though the last few years with predictable outcomes that is 
now for the most part, proved to be costly endeavors yielding little 
payoff, with high barriers and expense to revisit.

> problem.  

Sure, but unfortunately strategic product reframing is being done.

> In the broader sense there are lots of opinions and perspectives, 
> but they don't help here.  

And thats because they don't match your Os and Ps? :)

> I don't think any of the points about marketing are 

But it is about Marketing.  What you believe should be the technical 
aspects of the Problem, the opinions and perspective is all about how 
you think the PRODUCT should be written, should work and operate to do 
something useful is all about marketing the results to people who will 
end up using it.

Been thing again I may be also cursed with another corporate QA motto 
and poster I still hanging on my wall:

           What comes first?

              Marketing or Technology?

Do I need to explain it? :)

> obsolete" 

Unfortunately, with uncertainly someone in the future will use it to 
throw the proverbial book at someone - "SenderID is obsolete so stop 
talking about it."