Subject: [apps-discuss] Updating the status of SPF

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Aug 2011 11:22:47 -0700

Hi, apps folk.

A participant in another WG has expressed interest in republishing SPF (RFC4408) on the standards track.  This clearly and historically falls into the APPS realm.  The work is probably in need of a WG home, and with YAM leaning toward spinning down, this is the next best place to ask.  I have some doubts it would be accepted as sponsored individual submission nor is it appropriate for the ISE, but I could be wrong.

I doubt this warrants its own working group, but I could be wrong about that too.  So far as I'm aware the only changes needed from that document are the creation of an extensions registry, some minor editorial stuff, and some kind of resolution of the IESG Statement that was added to it to address the collision with Sender ID (RFC4406/7).

I socialized this with a few of you outside of the meeting in Quebec City and there wasn't any resistance to the idea; in fact one person who's typically not a fan of SPF even said it's something we should really do because it's still in widespread use.

Comments?

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Aug 2011 16:02:49 -0400

> A participant in another WG has expressed interest in republishing SPF
> (RFC4408) on the standards track.  This clearly and historically falls into
> the APPS realm.  The work is probably in need of a WG home, and with YAM
> leaning toward spinning down, this is the next best place to ask.  I have
> some doubts it would be accepted as sponsored individual submission nor is
> it appropriate for the ISE, but I could be wrong.

It absolutely can not be done in the Independent Stream -- that stream
can't do Standards Tack documents.

> I doubt this warrants its own working group, but I could be wrong about that
> too.  So far as I’m aware the only changes needed from that document are the
> creation of an extensions registry, some minor editorial stuff, and some
> kind of resolution of the IESG Statement that was added to it to address the
> collision with Sender ID (RFC4406/7).

I believe this absolutely needs its own WG, and the proponents should
work on a draft charter.  The charter should be clear that it's aiming
to move SPF to Standards Track, that it is specifically NOT addressing
Sender-ID, and that any merging of Sender-ID into SPF is out of scope.
 The charter should have explanatory text about the experiment having
been done, the results being clear, and deployment being widespread.
The WG wants, it should say, to document the experimental results and
shift SPF onto Standards Track.

Hatless Barry

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 8 Aug 2011 17:40:02 -0700

> shift SPF onto Standards Track.

+1, particularly regarding documenting the results.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Aug 2011 18:27:26 -0700 (PDT)

> +1, particularly regarding documenting the results.

+1. If this needs doing, this is how to do it.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Aug 2011 12:57:56 +0200

> shift SPF onto Standards Track.

+1, this is a Good Thing to do!

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Aug 2011 12:03:20 +0100

> shift SPF onto Standards Track.
Considering past history of SPF/Sender-ID, I would advise Apps AD not to 
take it as an AD-sponsored document. So +1 for the WG, if there is 
energy to do the work.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Aug 2011 10:19:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, August 09, 2011 3:58 AM
> To: [email-masked]
> Subject: Re: [apps-discuss] Updating the status of SPF
> 

Does that mean you (all) are volunteering to review stuff and comment, and possibly co-chair?

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 9 Aug 2011 10:28:28 -0700

> Does that mean you (all) are volunteering to review stuff and comment, and possibly co-chair?

Sure, I'll review and comment.

---

From: "John Levine" <[email-masked]>
Date: 9 Aug 2011 22:54:15 -0000

>Does that mean you (all) are volunteering to review stuff and
 comment, and possibly co-chair?

I'll review stuff, but someone who thinks SPF is important needs to
step up and offer to chair.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Aug 2011 17:11:30 -0700

> Does that mean you (all) are volunteering to review stuff and comment, and possibly co-chair?

I'll offer to co-chair.

There's some history to this effort, going back to MAAWG, where I was one of 3 
folk raising their hands to pursue this.  Somehow things wandered through a 
circuitous route and I got decoupled from it.

Historically and vocally, I'm not a fan of SPF.  However I am /always/ a fan of 
good documentation for existing practice and I don't believe in using 
documentation processes to exercise religious preference.  An effort to produce 
tight, pragmatic SPF documentation should be accurate and usable.

I offered to assist the effort both to navigate the politics and to press for 
clean workable documentation.

I'll suggest, however, that there is good reason for concern about any 
expectation that this will be a simple and/or easy effort.  It will be wonderful 
for that to happen, but SPF invites the contrary.

A few tidbits as examples:

   *  It uses TXT without an underscore, thereby inviting the classic scaling 
argument against using TXT.  This invites pushback from the DNS folk.

   *  It is based on an implied semantic of SMTP Mail From that correlates with 
actual use, but not formal semantics of the field.  This invites pushback from 
(some) email folk.

   *  It is used for anti-abuse.  This invites pushback from anyone who thinks 
they are an expert in anti-abuse and has any sort of agenda, releant or not, and 
we've already seem plenty of that over the last 7-9 years.

While this probably does need a working group, it most definitely needs a 
collaborative, core design team that shares a coherent and constrained set of 
goals for the effort and that can work together.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 9 Aug 2011 23:37:39 -0400

On Tuesday, August 09, 2011 01:19:58 PM Murray S. Kucherawy wrote:
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Alessandro Vesely

I've already started locally looking at what changes need to be made in RFC 
and updating the draft.  There are a few errata, but I doubt there is a lot to 
do.  

If a full working group is needed, I'm willing to work in any role (in 
addition to co-authoring) if the group is suitably chartered.  I've also had 
informal discussions with one of the RFC 4408 co-authors that is willing to 
also work on 4408bis.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 10 Aug 2011 14:22:07 +0200

On 8 August 2011 20:22, Murray S. Kucherawy wrote:

> So far as I’m aware the only changes needed from that document are the
> creation of an extensions registry, some minor editorial stuff, and
> some kind of resolution of the IESG Statement that was added to it to
> address the collision with Sender ID (RFC4406/7).

Yes, the IESG review of the "errata hosted elsewhere" (= openspf.org)
resulted in "submit new RFC"; only HTTP got away with the slightly odd
approach of "hosting errata elsewhere".  Of course it was not odd when
the HTTP folks did it, but admittedly it is not more state of the art.

A new RFC can adopt the collected errata, and report various results
of the experiment, e.g., the test suite, a reference implementation,
and the missing EAI followup (= expired I-D unrelated to new EAI work).

IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is now a
not completely irrelevant result -- that SPF started earlier will never
change, and at some point in time adoption has to mean something.

DKIM started after SenderID, and it is already far beyond this level in
the same study.  It's not something that should be mentioned in an RFC,
but it is a motivation to work on a refresh version covering all errata,
and with updated references, e.g., RFC 5321/2 instead of RFC 2821/2.

The SPF modifier registry could be also started in a MARF RFC, starting
a registry as soon as it *might* be used can be too early if it is in
fact never updated later, starting it as soon as there is more than
one RFC needing values in the same namespace could be a good plan.
But for
the SPF modifiers it would be clearer to start the registry in 4408bis,
if that is possible, because the MARF use case are "special modifiers",
not the place where readers would expect details of a general concept.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Aug 2011 08:14:10 -0700

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2011 5:22 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Given the history, maybe this is a case where an implementation report, normally used to promote something to Draft Standard, would be especially helpful?

> one RFC needing values in the same namespace could be a good plan. But for

I think it would best appear here, but I don't have a problem doing it in the MARF extensions draft to which you are referring.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Aug 2011 09:17:08 -0600

<hat type='individual'/>

On 8/10/11 9:14 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: Frank Ellermann
>> [mailto:[email-masked]] Sent: Wednesday,
>> August 10, 2011 5:22 AM To: Murray S. Kucherawy Cc:
>> [email-masked] Subject: Re: [apps-discuss] Updating the
>> status of SPF
>> 
>> IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is
>> now a not completely irrelevant result -- that SPF started earlier
>> will never change, and at some point in time adoption has to mean
>> something.
>> 
>> DKIM started after SenderID, and it is already far beyond this
>> level in the same study.  It's not something that should be
>> mentioned in an RFC, but it is a motivation to work on a refresh
>> version covering all errata, and with updated references, e.g., RFC
>> 5321/2 instead of RFC 2821/2.
> 
> Given the history, maybe this is a case where an implementation
> report, normally used to promote something to Draft Standard, would
> be especially helpful?

Given that the SPF spec is Experimental, I agree that a report on the
experiment would be useful.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Mehnle <[email-masked]>
Date: Wed, 10 Aug 2011 16:16:03 +0000

All,

I'm willing to contribute to this effort to whatever reasonable extent 
necessary to make it happen.

-Julian

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Aug 2011 19:21:29 +0200

> step up and offer to chair.

So will I, and I thank the members of the SPF council who offered to chair.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Aug 2011 12:09:58 -0400

OK... so unless my co-chairs or the ADs object, I'm happy with letting
initial charter discussion happen here.  Who will post a draft charter
proposal, and when?  Once things get started and a reasonable charter
looks like it's coming together, y'all can ask the ADs for a mailing
list to take the discussion further, and to get into the details.

Note that I suggest you NOT use the existing spf-discuss list, to keep
the IETF work on an IETF mailing list.  People from spf-discuss that
are interested in working on the IETF documentation should be
encouraged to come to the IETF lists for that.

If you do decide to start the charter discussion here, please keep it
to charter stuff, and save details for an SPF mailing list when it's
created.

Barry, appsawg chair

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Aug 2011 10:32:52 -0600

<hat type='AD'/>

> to charter stuff, and save details for an SPF mailing list when it's

Barry, that all seems reasonable to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Aug 2011 09:40:19 -0700

> and updating the draft.  There are a few errata, but I doubt there is a lot to

Scott,

What are the criteria you are using to determine what should be changed?  What 
is the basis for using those criteria?  For example, what is the likelihood that 
others in the community will agree with your choices?

d/

-- 

   Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Aug 2011 19:10:50 +0200

> to charter stuff, and save details for an SPF mailing list when it's

Some hopefully simple and hopefully harmless proposals for a charter:

- 4408bis shall create (= define) a IANA registry of SPF modifiers
  based on the existing MARF draft.  Rationale: that is what triggered
  this discussion.
- 4408bis shall fix all 4408 errata listed on the RFC editor page and
  the corresponding openspf.org errata page (unmodified since 2008-08,
  same rationale as above).
- 4408bis shall address potential abuses of the SPF "mx" mechanism in
  "security considerations" and/or suggest improved mitigations, if
  the WG decides that 4408 can be improved wrt DNS attacks.  It is no
  rationale, but I think we can now say that the concerns of Doug Otis
  were slightly exaggerated (the Internet still exists), but no patent
  nonsense.
- 4408bis may create a registry of DNS TXT and SPF RR "SPF version
  prefixes", if the WG decides that this would help with other uses of
  DNS TXT and SPF RRs (notably SenderId).  Rationale: Maybe that could
  help with Dave Crocker's concerns and/or known EDNS0 limitations in
  practice; at least the WG should be free to tackle it (if desired).
- 4408bis shall cover relevant results of the experiment since RFC 4408
  was published.  Rationale: Pointers to the existing SPF test suite
  and reference implementation can't be wrong, and EDNS0 observations
  in a recent "Netalyzr" publication are IMO also relevant.
- 4408bis shall be on standards track, and contain any known relevant
  info for future SPF implementation reports.
- 4408bis shall contain "i18n considerations" for the known "exp" URL
  case (here no news are good news), and its relation to EAI and IDNA.
  Rationale: Here be dragons.
- 4408bis shall recommend the now existing proper mail header field
  in favour of its own Received-SPF header field.  Rationale: It was
  still cute to create the first new trace header field in decades, or
  was it even the "first (period)"?

Regards,
 Frank
-- 
<http://www.openspf.org/Community/Lost-in-space>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Aug 2011 19:40:39 +0200

On 11 August 2011 18:40, Dave CROCKER wrote:

> What are the criteria you are using to determine what should be changed?

As far as the errata are concerned, that was a process in the OpenSPF.org
community reviewed on the mailing list (IIRC it was an "other IETF list"
before 2008-08) and in the SPF Council.  All results were published on
<URL:http://www.openspf.org/RFC_4408/Errata>, submitted to the RFC editor,
and reviewed by the IESG in 2010-07, who recommended to tackle this in a
new RFC:  <http://www.rfc-editor.org/errata_search.php?rfc=4408&eid=994>.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Aug 2011 10:42:30 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Thursday, August 11, 2011 10:11 AM
> To: Barry Leiba
> Cc: [email-masked] Discuss

This might be addressed by publishing an implementation report akin to what we typically produce when promoting something to Draft Standard, focused on "the experiment" and its results.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 13:51:33 -0400

> Some hopefully simple and hopefully harmless proposals for a charter:

<Frank's proposal>

I think these are all reasonable points for discussion.  

I am concerned that the charter should give weight to preserving backward 
compatibility.  If there are severe problems that would require breaking 
backward compatibility, then obviously they can't be ignored, but the protocol 
has been widely used in production for many, many years and that installed 
base should not be abandoned lightly.

There are some design points that could have been done better in hindsight, 
but I don't think these issues should be rehashed.

I'm not sure in IETF terms what the best way to address this in a charter 
would be.  Suggestions?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 13:52:08 -0400

On Thursday, August 11, 2011 01:42:30 PM Murray S. Kucherawy wrote:
> > [mailto:[email-masked]] On Behalf Of Frank Ellermann
> This might be addressed by publishing an implementation report akin to what
> we typically produce when promoting something to Draft Standard, focused
> on "the experiment" and its results.

This is something I can work on.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Aug 2011 10:53:22 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, August 11, 2011 10:52 AM

I would merely add a charter point saying something like "The working group shall ensure that no changes are made that prevent full backward compatibility with RFC4408 unless such changes are urgently needed."

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 13:57:54 -0400

On Thursday, August 11, 2011 12:40:19 PM Dave CROCKER wrote:
> > I've already started locally looking at what changes need to be made in
> > RFC and updating the draft.  There are a few errata, but I doubt there
> > is a lot to do.
> 
> Scott,
> 
> What is the basis for using those criteria?  For example, what is the
> likelihood that others in the community will agree with your choices?

So far all I've done is work on getting circa middle of the last decade XML to 
work with the current xml2rfc and started to gather errata and other issues to 
consider.

So far I haven't made any actual choices (that would be premature).

My intent is to have an appendix in the draft (that would be removed before 
final publication) to describe changes so it's easy to determine what's 
different from 4408 (and when the time comes, previous revisions).

I am, of course, open to feedback on this approach.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 13:58:51 -0400

On Thursday, August 11, 2011 01:53:22 PM Murray S. Kucherawy wrote:
> > [mailto:[email-masked]] On Behalf Of Scott Kitterman
> I would merely add a charter point saying something like "The working group
> shall ensure that no changes are made that prevent full backward
> compatibility with RFC4408 unless such changes are urgently needed."

That sounds good to me.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Aug 2011 10:59:31 -0700

> Sent: Thursday, August 11, 2011 10:58 AM

That's a BCP for these sorts of things, I've found.  For RFC4871bis, a lot of text changed, but very little was protocol-related.  It was important to have that summary in the document and also to have the output of "rfcdiff" comparing them available for perusal.

> I am, of course, open to feedback on this approach.

WFM so far.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Aug 2011 21:10:40 +0200

> WFM so far.

Same here after figuring out that this means "works for me".  There used to
be a kind of consensus in the OpenSPF community, that any future version
(neither v=spf1 nor spf2.0/anything) shall use only DNS SPF RRs (not TXT),
and the WG should be free to say so in 4408bis if desired.

The WG should be also free to say that spf2.0/anything for "mfrom" is now
considered as obsolescete for the purposes of v=spf1, with more details
to be determined by the WG as desired.  I'd like to have it clear that
4408bis does not require or care about any spf2.0/mfrom records as noted
in RFC 4406 section 4.4 clause 3, and that 4408bis shall be interpreted
as specified in 4408bis, notably not as in RFC 4406 section 4.4 clause 4.

This issue is already covered in the RFC 4408 security considerations, and
in its IESG note at the begin, therefore 440bis should have this as clear
as possible.  An attempt to combine this proposal with Barry's concerns:

"The WG shall not try to update other RFCs, notably 4405, 4406, 4407, or
 5321/5322, but may address the spf2.0/mfrom or hypothetical spf2.0/helo
 scopes wrt 4408bis security considerations."

-Frank

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Aug 2011 15:38:25 -0400

> shall ensure that no changes are made that prevent full backward compatibility
> with RFC4408 unless such changes are urgently needed."

I think the real point here is not just to *say* that, but to explain
what's going on.  Put it in the context of what the WG *is* and
*isn't* doing at this stage.

That means that what you want to say is that the working group is, at
this charter stage, documenting the *existing*, widely implemented
protocol, which has sufficiently broad, interoperable deployment to be
on Standards Track.  Say that there are suggestions for changes that
are not part of the current widespread implementation, some of which
are not backward compatible, and that *all* these changes (whether
backward compatible or not) could be in scope for a future recharter
or new working group, but are not in scope here.

Barry, as participant

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 15:46:05 -0400

> and the WG should be free to say so in 4408bis if desired.

I disagree.  Type SPF has almost zero deployment, so using only Type SPF is 
not consistent with preserving the installed base.

>  scopes wrt 4408bis security considerations."

I don't think the WG should do anything in 4408bis beyond updating 4408.  I 
don't think there's a need for any drafts relative to 4405/6/7 other than the 
one that declares them historic.

We can debate the DNS type issue later on the appropriate list once we have a 
solid charter.

If you feel the need, I think "The WG shall not try to update other RFCs." is 
sufficient.

Scott K

---

From: Julian Mehnle <[email-masked]>
Date: Thu, 11 Aug 2011 21:10:03 +0000

Frank Ellermann wrote:

> The WG should be also free to say that spf2.0/anything for "mfrom" is
> now considered as obsolescete for the purposes of v=spf1, with more
> details to be determined by the WG as desired.  I'd like to have it
> clear that 4408bis does not require or care about any spf2.0/mfrom
> records as noted in RFC 4406 section 4.4 clause 3, and that 4408bis
> shall be interpreted as specified in 4408bis, notably not as in RFC
> 4406 section 4.4 clause 4.
>
> This issue is already covered in the RFC 4408 security considerations,
> and in its IESG note at the begin, therefore 440bis should have this as
> clear as possible.  [...]

Whereas the note in the security considerations could be expanded or 
supported with whatever relevant evidence exists, I don't think 4408bis 
should even mention "spf2.0" or any of the 440{5,6,7} RFCs.  It never 
has, and I don't see a need for it to start doing so now.

-Julian

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Aug 2011 23:19:06 +0200

On 11 August 2011 21:46, Scott Kitterman wrote:

> I disagree.

Are you sure?  I wasn't talking about what works and is installed, but
about any future versions.  The IETF can certainly say what it intends
to do with the SPF RR, and it could even conclude that this was one of
the things that turned out to be bad ideas in both experiment(s).  But
I'd still say that "let's just (ab)use TXT" is not more necessary for
any "SPF 3" or "SenderID 3" as long as the SPF RR exists.

If you insist on it the WG should IMHO still be free to say whatever
it likes to say about the type 99 DNS SPF RR; maybe kill it for good.

> Type SPF has almost zero deployment, so using only Type SPF is not
> consistent with preserving the installed base.

We certainly don't disagree here, and this should be documented in a
4408bis.  Willing or not, in that case the SenderID experiment would
be forced to follow suit, because it is one of the points where it is
based on RFC 4408.

If the OpenSPF community arrived at new conclusions about the SPF RR
after the end of 2008 I missed it, please correct anything I write
where that might be the case.

> I don't think there's a need for any drafts relative to 4405/6/7 other
> than the one that declares them historic.

That would obviously solve the historic incompatibility between 4406
and 4408; and I'd be happy with any solution for 4408bis.  Above all
nobody should be forced to explain how the IETF managed to start two
subtly incompatible experiments after a new 4408bis is published.

> If you feel the need, I think "The WG shall not try to update other
> RFCs." is sufficient.

I feel the need to get rid of the incompatibility, and don't care how
this is done, as long as it is "thorough" :-)

-Frank

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Aug 2011 17:36:26 -0400

> it likes to say about the type 99 DNS SPF RR; maybe kill it for good.

The plain fact is that once a DNS RRTYPE is allocated, it can't be
"killed".  You can deprecate its use and tell new software not to look
it up.  But the code point will remain assigned, I predict, until we
stop using the DNS (which, at the rate we are adding lard to spackle
to baling-wire, might be any day now, but that's a digression for
another list).

For the little it us no doubt worth, it is the "TXT is now used
everywhere, and so we're not going to deprecate that even in new
versions of the protocol, pppptttthhht" argument that annoys people
who see the problems with TXT records whenever they're overloaded in
yet another protocol.  In effect, once you adopt TXT, you're going to
use it forever.  This same attitude is why we still have A-record MX
fallback all these years later.

But I do agree that, if people are wedded to using their bad idea
forever, one isn't going to change their mind, and it is silly to have
two mechanisms for achieving the same goal one of which is never used
(particularly if it causes additional DNS load).

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Aug 2011 14:41:01 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Thursday, August 11, 2011 2:36 PM
> This same attitude is why we still have A-record MX

This is the first time I've heard someone lament that old RFC974 provision.  I'll have to ask you to elaborate someday.

> (particularly if it causes additional DNS load).

I'm viewing this more and more as something we should handle the same as a PS-DS promotion; do an interoperability report (in this case, about "the experiment"), remove unused stuff, generally tidy up, resolve errata, and allow nothing else.

That SPF used TXT the way it did may be unfortunate, but as you said, we're not going to change it.  We should document the discussion and the results of years of deployment, hold our noses and live with it.  I'd also be fine with including verbose admonitions to future protocol designers NOT to use this as an example of possible TXT use in future protocols.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Aug 2011 18:07:04 -0400

> (particularly if it causes additional DNS load).

I feel strongly that the 4408bis effort we are discussing now should be a 
minimal/backwards compatible_unless_it_is_impossible update.  Once that is 
complete there is a backlog of incompatible design ideas for simplifying and 
improving SPF.  In that context I think moving to Type SPF only makes a lot of 
sense and should be considered.  I don't want to get that mixed in with the 
current effort.

I, for one, am certainly not wedded to the idea of using TXT forever.

Scott K

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Aug 2011 15:40:20 -0700

> or new working group, but are not in scope here.

+1

Otherwise, this WG will be little more than a big drawn-out argument.

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 12 Aug 2011 03:04:36 +0000

> or new working group, but are not in scope here.

Yes, *please* let's avoid any slippery slopes, lest this effort goes down 
the drain.

-Julian

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 12 Aug 2011 12:50:56 +0200

On 11.08.2011 23:41, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Andrew Sullivan
> That SPF used TXT the way it did may be unfortunate, but as you said,
> we're not going to change it.  We should document the discussion and the
> results of years of deployment, hold our noses and live with it.  I'd also
> be fine with including verbose admonitions to future protocol designers
> NOT to use this as an example of possible TXT use in future protocols.

Actually, SPF has already paved the way for a number of other protocols.  To
quote John Levine:

    We in the DKIM community were lucky that the SPFers
    already had those arrows in their backs.
        http://www.ietf.org/mail-archive/web/domainrep/current/msg00378.html

The discussion was quite thorough, and, if I haven't misread it, the
conclusion was that TXT records are the best option for this kind of use,
although such specs formally pollute a non-controlled namespace --somewhat
mitigated by leading underscores.

How about this?

    The working group shall document the existing, widely implemented
    protocol, which has sufficiently broad, interoperable deployment to be
    on Standards Track.  Capitalizing on the experience gained in the
    experiment, and taking advantage from newly established protocols, the
    working group may propose alternatives to the existing practices, or
    deprecate some of them, provided that all introduced changes are fully
    backward compatible with RFC 4408.  The working group shall not try to
    update other RFCs, although interoperability problems may be discussed,
    especially if they concern security considerations.

jm2c

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 09:14:57 -0400

> sense and should be considered.  I don't want to get that mixed in with the 

I don't have a strong feeling about this, but why is that a better
strategy?  If the goal is to move SPF off the EXPERIMENTAL track, then
surely the time to make changes to the protocol is when you move it
and determine the extent to which the experiment worked or didn't?
Cf. the current effort in the EAI WG.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Aug 2011 10:00:48 -0400

On Friday, August 12, 2011 09:14:57 AM Andrew Sullivan wrote:
> > minimal/backwards compatible_unless_it_is_impossible update.  Once that
> > is complete there is a backlog of incompatible design ideas for
> > simplifying and improving SPF.  In that context I think moving to Type
> > SPF only makes a lot of sense and should be considered.  I don't want to
> > get that mixed in with the current effort.
> 

It's in wide scale use.  The goal of the current effort is to document that 
use. 

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 10:21:10 -0400

> It's in wide scale use.  The goal of the current effort is to document that 

I don't know why a WG is necessary for that.  There are three
possibilities here.

One is that SPF as specified is in wide scale use, in which case there
is no real protocol work that is needed.  All that is needed is a
report (maybe as an RFC) saying, "This thing was widely deployed.  The
experiment worked."

If, however, the experiment did not work, or bits and pieces of the
RFC are not actually implemented or are implemented differently or are
implemented diffrently by different people, then the new effort can do
one of two things.  One is to move the experimental protocol to the
standards track.  But that automatically requires that one make some
determination about which pieces are going to change, and as Dave
Crocker said somewhere in this thread that is going to attract all
manner of disagreements.  The other is simply to document exactly what
is out there and how things do and do not deviate from the
experimental protocol.  The latter is surely an exercise in research
that delivers an informational document but does not move the protocol
onto the standards track.

In my view, if the goal is to move the protocol to the standards
track, then addressing issues in the protocol as already documented
(and as actually deployed) has to be an open possibility.  If that's
not the goal, then I have no objection.  I don't see what the value
would be in moving something to the standards track without being
willing to undertake standards work on it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Aug 2011 11:38:57 -0400

On Friday, August 12, 2011 10:21:10 AM Andrew Sullivan wrote:
> > It's in wide scale use.  The goal of the current effort is to document
> > that use.
> 

I can understand that view.  On the other hand, in the absence of data 
documenting deficiencies in the experimental protocol I think it would be 
imprudent to abandon the benefits of years of experience with running code.

My view is that the experiment was largely successful and only minor changes 
based on this experience are necessary.  It may be that during the work of the 
group other information will come to light that will cause me to change that 
view.  I'm not saying don't deviate, but give due weight to the experience 
with the current design and running code and don't deviate other than to fix 
significant issues.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 12:19:03 -0400

On Fri, Aug 12, 2011 at 11:38:57AM -0400, Scott Kitterman wrote:

> based on this experience are necessary.

This is the problem I'm focussed on, however: once you say, "My
changes are minor, $someone's are not in scope," you basically open up
the protocol by having to debate the values of "my" and "minor" (and,
too often I find, "changes").

I really don't have a dog in this race: I don't care about SPF, and
the TXT battle was lost a long time ago.  I'm just saying that, if the
goal really is supposed to be, "Just document what's happened," you
don't need a WG and you don't need to move tracks.  You need a
document that outlines what happened, period.  That will more readily
achieve the goal of documenting actual existing practice and getting
the document out in a reasonable time frame.  Everything else
effectively means that you have to deal with all the issues Dave
Crocker correctly identified.

At the same time, I am strongly opposed, on process grounds, to a WG
whose task it is to move a protocol from the experimental track to the
standards track without facing any of the questions about whether the
experiment worked, the extent of that working, and the trade-offs that
might have been acceptable in an experiment but that are not
acceptable for anything we might call a standard.  If there is to be
any distinction at all between these tracks, then those questions must
be acceptable when changing.  Otherwise, we get an experimental track
that is just a new level in the 3 (soon to be (3-n)) level standards
track we already have.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Aug 2011 11:01:46 -0700

Scott,

I have some questions about the current draft of the charter.  For the moment, 
I'm merely trying to get a better understanding of what is intended:

>       Determining the trustworthiness of content on the Internet remains a

What is meant by "trustworthiness of content"?

Two examples are that it might mean that it really was created by the purported 
author.  Or it might mean that its contents are "valid" (which might invite some 
discussion about "validity", of course.) There are other possibilities.

> 	(RFC4871).  However, legitimate and illegitimate users alike can

What is an "illegitimate user"?

> 	take advantage of these schemes.  What is also required is a
> 	meaningful assessment of the trustworthiness of the identifier's
> 	owner.  This in turn permits making a meaningful choice about what
> 	to do with the associated content.

Is the work of the group intended to cover "what to do with the associated content"?

> 	The advent of the requirement described above creates a need to have
> 	reputation data providers make available to consumers data about

Does "consumers" mean end-users, operators of receiving services, or some other 
group?

If it means end-users, how are they expected to employ this information within 
the current context of the tools end-users have?

> 	An existing, standardized reputation query mechanism is
> 	Vouch-by-Reference (RFC5518), which provides a simple Boolean
> 	response concerning the acceptability of different types of mail.
> 	Other application spaces -- such as Web interactions -- could
> 	benefit from common reputation query mechanisms, especially those
> 	for which replies need to be more elaborate.

Given the existence of VBR, why is an additional reputation query mechanism 
needed?  What will be different in the the mechanism and why is the difference 
important?

Perhaps the new mechanism will be identical to VBR, but merely will have the 
meaning of the response be more general than just email?

> 	This working group will produce a set of documents defining and
> 	illustrating the requirement and defining mechanisms to satisfy it.
> 	Two mechanisms are proposed:
>
> 	* simple -- a reputation is expressed in a simple manner such as
> 		an integer
>
> 	* extended -- a response can contain more complex information
> 		useful to an assessor

Who is going to use each of these mechanisms and why?  Are they participating in 
the discussions so far?  Have they expressed interest in implementing the output 
of the working group?

>
> 	The mechanisms will be designed to be application-independent, and
> 	portable between reputation providers.

For this topic, what does 'application-independent' mean?

What does portable between providers mean?

> 	The group will also produce specifications for reporting reputation
> 	data from end-points (usually end users, such as someone clicking
> 	a "report spam" button in response to unwanted email, or a
> 	"thumbs-up" button in an online rating system) to reputation
> 	data aggregators for use in computing updated reputations.

Reporting to whom?

What will be the basis for choosing among the different possible and existing 
models for reporting spam?

The language appears to equate reporting by end-users with some other forms of 
reporting.  Is there really a basis for conflating these?

> 	Reputation systems such as Realtime Block Lists (RBLs, RFC5782)
> 	can be problematic when not operated properly.  For example, an
> 	RBL that lists a specific source without justification can do harm

By 'source' I assume the meaning is of an listed problem domain, rather than the 
source of the report that the domain is a problem?

> 	to a legitimate business, provoking damages and possible litigation.
> 	This important topic will need to be discussed in the informational
> 	portions of the work produced here, in terms of advice both to

What is meant by "informational portions of the work"?  What output does that 
refer to?

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Aug 2011 14:14:39 -0400

On Friday, August 12, 2011 02:01:46 PM Dave CROCKER wrote:
> Two examples are that it might mean that it really was created by the
> purported author.  Or it might mean that its contents are "valid" (which
> might invite some discussion about "validity", of course.) There are other
> possibilities.
> 
> Does "consumers" mean end-users, operators of receiving services, or some
> other group?
> 
> If it means end-users, how are they expected to employ this information
> within the current context of the tools end-users have?
> 
> needed?  What will be different in the the mechanism and why is the
> difference important?
> 
> Perhaps the new mechanism will be identical to VBR, but merely will have
> the meaning of the response be more general than just email?
> 
> Who is going to use each of these mechanisms and why?  Are they
> participating in the discussions so far?  Have they expressed interest in
> implementing the output of the working group?
> 
> What will be the basis for choosing among the different possible and
> existing models for reporting spam?
> 
> The language appears to equate reporting by end-users with some other forms
> of reporting.  Is there really a basis for conflating these?
> 
> By 'source' I assume the meaning is of an listed problem domain, rather
> than the source of the report that the domain is a problem?
> 
> What is meant by "informational portions of the work"?  What output does
> that refer to?

Several people have made suggestions re: a charter to investigate updating RFC 
4408.  I am working on a draft that integrates these comments and distils them 
down a bit.  From you comments though, I think you may have mistaken the 
DOMAINREP charter that Murray pointed to as an example for a draft charter for 
this new proposed work.  It's not.

Please clarify?

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Aug 2011 11:24:25 -0700

oh boy. sorry.  completely misposted.

sigh.

d/

On 8/12/2011 11:14 AM, Scott Kitterman wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Aug 2011 17:29:09 -0400

On Friday, August 12, 2011 12:19:03 PM Andrew Sullivan wrote:
> > My view is that the experiment was largely successful and only minor
> > changes based on this experience are necessary.
> 

I see three possible conclusions a working group might reach:

1.  The experiment was successful and with minor adjustments the protocol is 
suitable for standards track.

2.  The experiment had some good points, but identified significant issues that 
require substantial change, but we can make them and move on to the standards 
track.

3.  The experiment is not yet mature and after revision we need to repeat the 
experiment some more as an update experimental protocoal.

The evidence I'm aware of points to number one as the most likely result of 
doing this work.  I would prefer an initial charter that is oriented on this 
path to minimize the amount of time that needs to be spent on bikeshed 
discussions.

That does not mean that I think the WG should be blind to data that points to 
outcomes two or three.  If that's where the rough consensus goes, then that's 
where it goes.  In the interests of being efficient about the most likely path 
I'd rather come back and recharter for that type of work if it proves to be 
necessary.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2011 18:24:39 -0400

On Fri, Aug 12, 2011 at 05:29:09PM -0400, Scott Kitterman wrote:

> doing this work.

Fully agree.

> I would prefer an initial charter that is oriented on this 

No.  This is exactly the process objection I have.  If SPF is supposed
to jump tracks, then everybody's live issues get to come out, or
nobody's do.  I made an analogy with EAI before, and one reason I did
was because their focus on mostly modest changes has been enabled
exactly by the short duration of the experiment.  

A so-called experiment that has run as long as SPF (it was published
five years ago) should not be moved to the standards track without the
opportunity for everyone who thinks there's a problem to have hits.
Those people can be ruled out by the WG as unrealistic given the
deployed base, but they ought not to be ruled out by administrative
fiat (which is what keeping the charter so narrow entails).  This
isn't to say I think that a standards-track SPF that is 4408bis, with
only niggling changes, is wrong.  I'm just opposed to making that a
rule for a WG that is also moving SPF to the standards track.  If we
make such a rule, we are in effect making the experimental track step
0 of the standards track (if you count from 1, else s/0/-1/).  In this
age where we are dying to get rid of standards levels, I think adding
experimental to the front is a bad idea.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 13 Aug 2011 19:36:26 +0200

On 13 August 2011 00:24, Andrew Sullivan wrote:

> This is exactly the process objection I have.

Hi, I'm not sure how obvious this is for others, but SPF
is completely unsuited as an "example" or "precedence" in
more general two vs. three steps procedural discussions.

When RFC 4408 was published as an "IETF experiment" SPF
was already widely deployed, and the RFC was in fact the
result of experiments based on earlier Internet drafts,
and submitted as a "proposed standard".

For let's say "non-technical reasons" it ended up as an
experimental RFC, and anybody interested in the details
can dig through old MARID and spf-discuss mail archives,
or try to reconstruct the SPF history from footnotes in
the appeal to the IAB -- NOT RECOMMENDED unless you have
a grim sense of humour.

In other words, SPF is not really the first incarnation
of a new "four steps" procedure, but there are certainly
errata justifying a 4408bis, and I'd be interested to
work on that if it is for "standard tracks".  Otherwise
I'd say that implementors should find the errata page on
openspf.org, its URL is not affected by the "status" of
erratum 994.

-Frank