Subject: [marf] Working group status

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Dec 2011 12:38:23 -0800

Hello all,

Your co-chairs have been re-evaluating our progress as a working group, concerned with our declining productivity and lack of substantive and timely document reviews.  We're wondering if there's still interest in continuing this work, or if we should start the process of spinning down.

Here's where we're at on our current deliverables:

-          ARF applicability statement: exists, but no recent activity

-          Auth-failure report format: Completed two Last Calls; awaiting a (hopefully final) round of edits

-          DKIM reporting: exists, but no recent activity

-          Redaction draft: In IETF last call until 12/15

-          Reporting discovery: exists, but no recent activity

-          SPF reporting: exists, but no recent activity

-          SpamRep convergence plan: none

We feel that SpamRep has fallen out of favour on the OMA side.  Their working group's chair considers the activity "stalled" as there have been no implementation reports since they published their candidate specification.  It doesn't make much sense for us to expend energy to figure out a convergence plan given this, plus we have not been successful at identifying a champion in MARF for that work.  Thus, we don't believe it's practical for MARF to pursue this deliverable.

So by way of taking the pulse of the working group, here are some questions about what's left:

For draft-ietf-marf-as:
Do we feel we want to simply endorse the use of ARF as it is defined in RFC5965 and RFC6449, or do we wish to give different operational advice than what they say?  In the absence of any of the latter, the former is low-hanging fruit, which means we can close out that charter item rather easily.  But it has to reflect consensus either way.

For draft-ietf-marf-authfailure-report:
This last round of edits should be enough to send it to the IESG.

For draft-ietf-marf-dkim-reporting:
<participant> I would like to revisit this once more, especially based on John and Steve's feedback from about a month ago.  I'll do so in a separate thread.  I've found this work to be very helpful in the last several years and it would be helpful to write down a way to do what it's trying to do, even if different from what was originally developed. Is there interest in helping me to do so? </participant>
<co-chair> If the working group doesn't wish to pursue this at all, it can be returned to an individual submission for publication via that route. </co-chair>

For draft-ietf-marf-reporting-discovery:
Does the working group feel this work is useful to pursue?  If so, is there someone willing to step forward and act as editor?

For draft-ietf-marf-spf-reporting:
Does the working group feel this work is useful to pursue?  If not, we will suggest it be added to the proposed charter for SPFBIS or a future version of it.

Thanks,
-MSK, as co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Dec 2011 15:45:06 -0500

On 12/06/2011 03:38 PM, Murray S. Kucherawy wrote:
> For draft-ietf-marf-spf-reporting: Does the working group feel this
> work is useful to pursue?  If not, we will suggest it be added to the
> proposed charter for SPFBIS or a future version of it.

I think it has value.  I haven't updated the draft because it didn't
seem fruitful.  Things I'm waiting for:

draft-ietf-marf-authfailure-report: Waiting for the final post-last call
draft - since I'm waiting on the SPFbis situation to clarify a bit, my
intent was to wait until this draft was also ~final so I'd have a stable
base  to work from.

SPFbis:  I'm waiting for the charter discussion to settle out so that I
know how to deal with the downref issue to RFC 4408.  If the charter
lands the way I think it will, I think allowing a downref is justifiable.

Given those, I expect I can get another draft out in the next few weeks
if the WG is interested in pursuing it.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 7 Dec 2011 17:48:09 +0100

> For draft-ietf-marf-dkim-reporting:
[...]
> <co-chair> If the working group doesn’t wish to pursue this at all,
> it can be returned to an individual submission for publication via
> that route. </co-chair>

It is rather strange to close a WG when an almost-ready I-D exists,
a recent example was YAM and 5321bis.  OTOH I'm not competent to say
much about DKIM ARF, excluding editorial ABNF nits or similar issues.
As long as Barry is willing to shepherd your DKIM I-D here go for it.

> For draft-ietf-marf-spf-reporting:

When you asked who is willing to implement it, did you ever get a
response`?  Obviously Scott would, otherwise he wouldn't bother to
specify it.  For any SPF modifier there are general considerations:

- If potential users already have the required info as part of an
  SPF policy in an DNS cache they don't need convoluted additional
  "discovery" or "query" procedures.  That's good.
- If potential policy publishers are already very near to practical
  EDNS0 limits adding more info could make it worse.
- For new modifiers it should be clear that their introduction has
  no effect on existing old SPF policies without this new modifier.

As soon as there is more than one RFC talking about "SPF modifiers"
there should be a third RFC defining a registry for "SPF modifiers"
before it gets out of hand.  As far as MARF is concerned, could SPF
and DKIM reporting also be merged, or would that upset parts of the
intended audience?

-Frank

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Dec 2011 12:21:49 -0500

> and DKIM reporting also be merged, or would that upset parts of the

The current draft includes such a registry.

I've seen a number of deployed cases where the data provided would have
been very useful.  I believe it will be implemented to assist in
troubleshooting deployment problems (of which there is no shortage).

We had a long discussion earlier in the year (or was it last year) about
how the drafts should be split.  I think it would have been fine to keep
them all in one draft, but that wasn't the working group consensus.
Given that, let's not mess with document splits again and just press to
closure.

Scott K

---

From: SM <[email-masked]>
Date: Wed, 07 Dec 2011 09:43:16 -0800

Hi Frank,
>It is rather strange to close a WG when an almost-ready I-D exists,

The W generally implies "working".  There was a WGLC on 
draft-ietf-marf-redaction.  Six people, including the WG Chairs, 
commented on the draft.  The WG co-chair commented [1] on the lack of 
substantive and timely document reviews.

An almost-ready I-D is not good enough.  The WG co-chairs have to 
demonstrate to the Responsible AD that the work is moving forward and 
that the deliverables are receiving adequate review to be ready for 
publication.  Obviously, the WG co-chairs can only do that if the WG 
participants actually participate in the work.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/marf/current/msg01527.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Dec 2011 09:56:56 -0800

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2011 8:48 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Working group status
> 
> It is rather strange to close a WG when an almost-ready I-D exists, a
> recent example was YAM and 5321bis.  OTOH I'm not competent to say much
> about DKIM ARF, excluding editorial ABNF nits or similar issues.

The WG wouldn't close if there's active work on any of the drafts.  My concern is that there isn't.  We have a pattern of asking for review comments, not getting any, starting a working group last call, maybe getting some, then requesting through the AD an IETF-wide last call, and only then do we get some feedback.

We don't need a working group if the only meaningful phase of that cycle is the IETF-wide last call.  We get that automatically with AD-sponsored documents.

We wouldn't make a formal working group shutdown decision until all documents that have received enough feedback to justify the push to publication are in the IESG queue.  But we're not going to wait for a bunch of work to happen if it looks like it won't.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 7 Dec 2011 19:26:53 +0100

> Given that, let's not mess with document splits again and just press to

ACK, I missed or forgot that, no problem.

(Checking the archive, apparently my 1st comment was in August:
 <http://www.ietf.org/mail-archive/web/marf/current/msg01261.html>)

On 7 December 2011 18:43, SM <[email-masked]> wrote:

> demonstrate to the Responsible AD that the work is moving forward
> and that the deliverables are receiving adequate review to be ready
> for publication.

Well, there are three folks in the IETF where I'd automatically say
yes when they agree on an I-D about "BiDi", RTL or LTR or bottom-up
top-down boustrophedon.  Likewise I'd trust that JohnL and Murray
and Scott know what is good for the purposes of "abuse reporting".

IOW, I see no advantages to switch this draft to "individual" now.
Are you saying that you disagree, or did you only explain how this
is supposed to work?

-Frank

---

From: SM <[email-masked]>
Date: Wed, 07 Dec 2011 11:23:05 -0800

Hi Frank,
>Are you saying that you disagree, or did you only explain how this

Having only three people reviewing a draft is not how this is 
supposed to work.  The work being done in this WG is easy.  Each 
participants can help by putting in some time and effort to read the 
I-Ds and comment on them.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Dec 2011 11:58:13 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Wednesday, December 07, 2011 10:27 AM
> To: Scott Kitterman; SM
> Cc: [email-masked]

All of the MARF drafts are in one of two buckets:

1) The working group wants to finish what it started, in which case the document will continue where it is now until it proceeds to the IESG for publication.

2) The working group doesn't care about the topic enough anymore to work on it, in which case the document can find another home, either in another working group or as an individual submission, or perhaps in the independent stream, or the draft can simply expire.

The working group will stay alive until the documents are all squarely in either of those buckets, and all of the stuff in the first one has been sent through the publication process.  We're doing the "sorting" part now.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 08 Dec 2011 09:29:18 +0100

>> proposed charter for SPFBIS or a future version of it.

I'm not clear on what is the intersection MARF ∩ SPFBIS, but if it is
consistent enough the move can be done even in case we consider this
work to be useful to pursue.

> intent was to wait until this draft was also ~final so I'd have a stable

Since the other WG seems to be going to last longer than this, waiting
there may be more consistent.

> lands the way I think it will, I think allowing a downref is justifiable.

Some coordination can be fruitful here.  For example, if there will be
methods to report certain circumstances to the domain owners, then
some features of SPF that are only used for monitoring those
circumstances could be safely deprecated.  Contribution to such
monitoring is spontaneous and consenting in either case, but
decoupling it from SPF checking may remove an impediment toward
broader adoption.

jm2c

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Dec 2011 10:21:18 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, December 08, 2011 12:29 AM
> To: [email-masked]
> Subject: [marf] Moving spf-reporting to spfbis, was Working group
> status
> 

The SPF reporting draft includes work regarding feedback loops with respect to SPF failures.  Because of this it could legitimately be placed in either working group.  I don't see a clear way to split it into two documents, one going to each working group, without making it particularly ugly.  Then again, I haven't thought about it very much yet.

> > SPFbis:  I'm waiting for the charter discussion to settle out so that
> > I know how to deal with the downref issue to RFC 4408.  If the charter
> methods to report certain circumstances to the domain owners, then some
> features of SPF that are only used for monitoring those circumstances
> could be safely deprecated.  Contribution to such monitoring is
> spontaneous and consenting in either case, but decoupling it from SPF
> checking may remove an impediment toward broader adoption.

We have a few options here:

a) Downgrade spf-reporting to Experimental.

b) Pursue spf-reporting publication on the Standards Track, acknowledging the downref.

c) Pursue spf-reporting publication on the Standards Track, referencing SPFbis instead of RFC4408.  This will cause spf-reporting to be held by the RFC Editor until SPFbis publishes, but it's still a path forward.

It all depends on how much uptake we get in the short term.  If there isn't any, we might give (a) some serious consideration.  Same for dkim-reporting.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Dec 2011 18:01:11 +0100

On 08/Dec/11 19:21, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
> 
> c) Pursue spf-reporting publication on the Standards Track,
> referencing SPFbis instead of RFC4408.  This will cause
> spf-reporting to be held by the RFC Editor until SPFbis publishes,
> but it's still a path forward.

I'd vote for option (c).  SPFbis is not expected to bring fundamental
changes to the protocol.  However, together with spf-reporting it can
compose enough of an innovation to imply some sort of revision by most
alive implementations.

Early adopters of authfailure-report can already see that SPF is one
of the methods provided for, and code or plan accordingly.

> It all depends on how much uptake we get in the short term.  If
> there isn't any, we might give (a) some serious consideration.
> Same for dkim-reporting.

I'd figure dkim-reporting can get out more or less together with
authfailure-report.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Dec 2011 12:12:26 -0500

Alessandro Vesely <[email-masked]> wrote:

>some

My plan is to work towards option (b) unless there's some better consensus developed around one of the other choices.

Option (a) would require an update later after 4408bis is published. Since there's almost no chance (given the way the SPFbis charter discussions are going) that 4408bis will be materially different relative to this group's work, I think such an update wouldn't be a low value added use of time.

Similarly, I think waiting for 4408bis to publish would be pointless waiting. I'm aware of likely implementors and waiting won't help them either.

Scott K

---

From: Dotzero <[email-masked]>
Date: Wed, 14 Dec 2011 12:59:57 -0500

> Similarly, I think waiting for 4408bis to publish would be pointless waiting. I'm aware of likely implementors and waiting won't help them either.

This makes the msot sense to me.

Mike

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 14 Dec 2011 13:06:50 -0500

In <[email-masked]>, on
12/14/2011
   at 12:12 PM, Scott Kitterman <[email-masked]> said:

>My plan is to work towards option (b) unless there's some better
>consensus developed around one of the other choices.

Well, my preference is (c), but I understand your reasoning in favor
of (b).

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Dec 2011 13:07:38 -0500

> In <[email-masked]>, on

There's no guarantee that the downref will be acceptable.  If not, (c) would 
be my fall back plan if it were just up to me.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 10:40:29 -0800

> Sent: Wednesday, December 14, 2011 9:01 AM
> To: [email-masked]
> Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status
> 

Given the small amount of feedback on it so far, most of which suggests a complete revision of the approach, that doesn't seem likely.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Dec 2011 20:04:27 +0100

On 14/Dec/11 18:12, Scott Kitterman wrote:
> Option (a) [...]
> Similarly, I think waiting for 4408bis to publish would be
> pointless waiting. I'm aware of likely implementors and waiting
> won't help them either.

In that case, it's fine to go for option (b).

I'm going to ask this question on the other list, anyway.