Subject: [spfbis] Call for adoption: draft-kitterman-4408bis

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Jun 2012 12:07:40 -0400

Dear colleagues,

Now that the document concluding the SPF experiment is well on its way
to publication, it is time for the WG to turn its attention to our
other chartered work item: a standards-track document for SPF.  Note
that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has
been filed for RFC 4408.

We would like the working group to consider adopting
draft-kitterman-4408bis as the basis for such a specification.  As the
charter explicitly mentions that draft as a possible basis for work,
it is the presumptive candidate for adoption.

If you have any objections against adoption of the draft please send
them to the mailing list before 18 June.  Please include an outline of
what the alternative draft will be like or an alternative draft.  If
there is such an objection, we will wait one additional week for that
alternative draft to materialize before taking a decision.

The date, 18 June, gives us one month prior to the date for WG agendas
to be posted for Vancouver.  We have requested a 30 minute meeting
slot in Vancouver.  If by 18 July we do not seem to have any need for
further discussion in Vancouver, we will cede the time.

Best regards,

SM & AS

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Jun 2012 12:54:47 -0400

> it is the presumptive candidate for adoption.

The draft is currently expired.  I'll publish a revision today or tomorrow to 
get it unexpired.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Mon, 11 Jun 2012 12:38:43 -0600

Makes sense, thank you for moving the process forward. +1

Alan M

On 6/11/2012 10:07 AM, Andrew Sullivan wrote:
> SM&  AS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Jun 2012 15:26:57 -0700

On Mon, Jun 11, 2012 at 9:07 AM, Andrew Sullivan <[email-masked]>wrote:

> [...]
I support adoption of that document.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Jun 2012 00:03:08 -0400

> it is the presumptive candidate for adoption.

+1, make sense.

> alternative draft to materialize before taking a decision.

I don't think we need a major change.  Three items come to mind:

1) Focus is a consolidation of concepts and functionality currently 
peppered throughout of the docs.

2) Opportunity to bring positive engineering conclusion to the 
"experimental" is an ideal document that considered the total SPF 
spectrum - the reality.  References are good enough, but I thought the 
single integrated piece - SUBMITTER as part of the check_host() 
function.  This was proposed in issue #4

       http://tools.ietf.org/wg/spfbis/trac/ticket/4

which seems to me to be mysteriously CLOSED for some reason. It seems 
all presumptuous without proper realistic integrated considerations. I 
hope you can understand ISSUE #4 should be reopen for a proper 
integrated SPF implementation engineering design consideration. Look 
at it this way, you can't ignore it and in the reality, 
implementations check_host() will be more than just two inputs, so at 
the very least, a text change to point that out is necessary.

3) To avoid high potential conflicts, draft-kitterman-4408bis has to 
start by removing talk about DKIM:

    In the interval since that statement, DKIM (see [RFC4871] was
    developed and achieved wide deployment.  Both Sender ID (as the
    protocol defined in RFC 4405, RFC 4406, and RFC 4407 was named) and
    DKIM target "message content", as described in [RFC5598], while SPF
    targets the "transit-handling envelope".  The success or failure of
    the Sender ID portion of this IESG experiment should be evaluated
    relative to DKIM.

DKIM is not SPF - two different models of reputation vs deterministic 
methods, respectively. Such integration needs to be done outside the 
SPF framework and specification.

Thanks

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 Jun 2012 00:08:40 -0400

> SPF framework and specification.

The separate draft the resolved the end of the so called experiments didn't 
exist when I wrote that.  It's OBE by that draft, so it'll go away.  Don't 
worry about it.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 Jun 2012 09:46:29 +0200

> that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has

Is this because there /has/ to be an IPR?  (Otherwise, I don't
understand why that patent would concern SPF, given that the
referenced IPR 434 was related to Sender ID only.)

> it is the presumptive candidate for adoption.

I'd like to note explicitly that, except for some minor changes, that
I-D matches the current RFC 4408.  I have nothing against adoption,
but the proposed I-D is nowhere near WGLC and there are many issues
that need to be addressed.

To mention a nit, I would s/E-Mail/email/ as per RFC Editor style
guide http://www.rfc-editor.org/rfc-style-guide/terms-online.txt

As for the experimental status, the IESG note mentions "there are
serious open issues", while our document seems to aim at closing the
experiment after considering the "concerns about using them in tandem"
only.

> further discussion in Vancouver, we will cede the time.

I hope that does not imply that there is nothing to be discussed about
SPF, and look forward to an open-minded meeting.

Regards

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2012 08:17:18 -0400

> referenced IPR 434 was related to Sender ID only.)

As the person who filed the IPR disclosure, I can tell you that it is
because someone pointed out
http://www.microsoft.com/openspecifications/en/us/programs/osp/security/default.aspx
to me.  That page clearly claims to cover RFC 4408.

> SPF, and look forward to an open-minded meeting.

As we said in the original note, adopting a document as the basis for
work does not mean that the document is ready.  It means that it is a
starting point for the work.

As for the meeting in Vancouver, we'll only meet in person if there
are things to sort out in person.  Most work can be done on the
mailing list.  But if there are apparently issues that are not moving
forward on the list, we'll meet in Vancouver.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 12 Jun 2012 20:10:03 -0000

>to me.  That page clearly claims to cover RFC 4408.

Not really.  If you follow the backlink, it says that Microsoft
promises not to sue you for patent infringement if you implement any
of a list of specifications including RFC 4408.  But it does not
assert that any of their patents actually cover RFC 4408.

IPR 434 referenced US patent application 10/684020, which has now
turned into issued patent 7,398,315.  That patent is rather opaque,
even as patents go, but in a quick read I don't see anything that
looks relevant to SPF.

I don't know whether anyone from Microsoft is still following this, but
it would be nice to see if they were willing to update the OSP page
to include 4408bis, just to put the concerns to bed.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2012 16:41:57 -0400

Hi,

On Tue, Jun 12, 2012 at 08:10:03PM -0000, John Levine wrote:

> Not really. […]  But it does not

I shouldn't have said "clearly".  My mistake.

I filed that 3d party IPR disclosure because it appeared to me that
there was a claim.  Also, there was IIRC a disclosure filed
against the MARID version of SPF, although I can't put my hands on it
this moment (after about 20 seconds of trying).  

But, if you read your Note Well, the IETF takes no position on IPR.
You have to make up your own mind.  Therefore, since you've all been
apprised of the IPR filing, we don't need to talk about the
correctness of the filing.  You can each make your own evaluation.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 Jun 2012 18:51:10 -0400

>to include 4408bis, just to put the concerns to bed.

If we get to pick, I'd rather the remove 4408. I've looked at the patent as well and was unable to detect anything relevant to 4408 through the patent speak.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Jun 2012 19:58:22 -0400

> Dear colleagues,
...
> it is the presumptive candidate for adoption.
...
As requested, I've posted a -01 to revive the draft.  See:

http://www.ietf.org/id/draft-kitterman-4408bis-01.txt

It's the same as 00 except I removed a paragraph the discussed resolution of 
the experiment, since that's already been addressed and added review of WG 
issue status to the TODO section that was already present.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Jun 2012 17:32:07 -0700

> issue status to the TODO section that was already present.
Some housekeeping to note for later:

Appendix C probably needs to be updated, especially the bit about the IESG
note.

Also, when we did DKIM it was suggested that the resolved errata be listed
by their numbers.  I don't recall if any of the ones you've got there were
tracked as errata on the RFC Editor site or just at openspf.org.  Should
they be opened as RFC Editor errata if they were only external?  Are there
any external tracking numbers that would be useful to add?  It helps people
evaluating the document to have this sort of thing as a sort of checklist
to ensure nothing's getting missed.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 13 Jun 2012 19:06:18 -0700

At 17:32 13-06-2012, Murray S. Kucherawy wrote:
>Appendix C probably needs to be updated, especially the bit about 
>the IESG note.

Please leave the current version as it is as there is a call for 
adoption currently.

>Also, when we did DKIM it was suggested that the resolved errata be 
>listed by their numbers.  I don't recall if any of the ones you've 
>got there were tracked as errata on the RFC Editor site or just at 
>openspf.org.  Should they be opened as RFC Editor errata if they 
>were only external?  Are there any external tracking numbers that 
>would be useful to add?  It helps people evaluating the document to 
>have this sort of thing as a sort of checklist to ensure nothing's 
>getting missed.

There is no need to file errata as there is an existing working group 
updating RFC 4408.  There are also existing tickets in the issue 
tracker for the errata and the issues raised during the review 
period.  It will likely be the starting point for the upcoming 
discussions.  The suggestion to list the erratum number also came up 
for work in a different working group.

I would like to discuss the above and other details with Andrew 
Sullivan to see how the work can be planned.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jun 2012 17:23:37 -0400

Dear colleagues,

> them to the mailing list before 18 June.

Nobody objected.  The draft is hereby adopted.

Scott Kitterman is appointed as editor of the WG document.  Scott, the
next version of the draft gets the filename
draft-ietf-spfbis-rfc4408bis-00.txt (and any xml or such like if you
wish).  Participants, in the meantime the draft-kitterman-4408bis-01
draft is in the datatracker as having been adopted.  Please read it.

As many of you know, there are open issues in WG's trac.  We will be
pulling them up.  In the meantime, if there are particular issues you
think are directly relevant for the draft, it would do no harm to add
the references to the trac tickets.  If you have new issues that
haven't been described yet, please describe them on the list.

The -experiment- process was, despite some frustration over the pace,
actually fairly successful I think, and so we're going to take a
similar approach here.  We're going to start by describing issues
first.  Therefore, I'd appreciate it if people took the next week to
describe any issues they have _without engaging in debate_ over the
issues.  Then we can prioritise issues and bring them to the list in
manageable chunks.  This will not be as simple as the case of
-experiment- because there are protocol issues at stake, but your
chairs think we can focus discussion this way and come to some
conclusions successfully.

Best regards,

Andrew (for the chairs)

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Jun 2012 14:40:10 -0700

> conclusions successfully.
Does this refer to issues not already present in the tracker?

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jun 2012 18:18:12 -0400

> Does this refer to issues not already present in the tracker?

Yes.  Sorry for being unclear.

Best,

A

-- 
Andrew Sullivan
[email-masked]