Subject: [marf] Proposed changes to draft-ietf-marf-as

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 05:30:00 +0000

Hello all,

I've got a diff between the current version and what I propose as our response to the two DISCUSS positions from the IESG about this draft.  Please review and comment ASAP.

The diff: http://www.blackops.org/~msk/marf-as.html

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 25 Apr 2012 11:06:54 +0200

> The diff: http://www.blackops.org/~msk/marf-as.html

  Further introduction to this topic may be found in [RFC6449],
  which	is effectively an Applicability Statement written outside of
  the IETF and thus never achieved IETF consensus. Much of the
  content for that document was input to this one.

That's a useful clarification, but possibly not as accurate as it
could.  If I knew IETF standardization enough, I'd propose text to say
what we mean to do, something along the lines of (AIUI):

  Further advice on this topic can be found in [RFC6449], which is
  effectively an Applicability Statement written outside of the
  IETF.  Rather than modify that document and then turn it into an
  IETF Standard, the IETF republished it as an Informational document
  and then publishes this document, which confers IETF Standard
  status to selected parts of the former one, while updating it as
  appropriate.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 09:49:28 -0400

On Wednesday, April 25, 2012 05:30:00 AM Murray S. Kucherawy wrote:
> Hello all,
> 
> I've got a diff between the current version and what I propose as our
> response to the two DISCUSS positions from the IESG about this draft. 
> Please review and comment ASAP.
> 

I don't find much value in the changes, but if that's what it takes to get 
approved, OK.  A few specific comments though:

 - The addition to section 4.5.1 isn't quite correct.  Elsewhere we tell 
report senders not to assume different types of reports will be treated 
differently, so I don't think there's any need for receivers to update to do 
so.  I think the most that can be said is that receivers ought to arrange for 
a reasonable default result if an unknown type is encountered.

 - Part of the diff starting page 7, line 4: How about anticipate or expect 
instead of believe.  Belief isn't much of an engineering term.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 13:53:35 +0000

> -----Original Message-----
> From: Scott Kitterman [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2012 6:49 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [marf] Proposed changes to draft-ietf-marf-as
> 
> I don't find much value in the changes, but if that's what it takes to
> get approved, OK.  A few specific comments though:
> 
>  - The addition to section 4.5.1 isn't quite correct.  Elsewhere we
> tell report senders not to assume different types of reports will be
> treated differently, so I don't think there's any need for receivers to
> update to do so.  I think the most that can be said is that receivers
> ought to arrange for a reasonable default result if an unknown type is
> encountered.

There issue is that we make it a MUST to accept all types listed in a registry.  How would an implementation do that?  There's no protocol to query the registry for new types, so it can't really be done live.  The IESG member is saying we need to explain to people what's involved in satisfying that MUST.

>  - Part of the diff starting page 7, line 4: How about anticipate or
> expect instead of believe.  Belief isn't much of an engineering term.

Good point.  We can patch that up with an RFC Editor note, unless another new version is warranted.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 10:08:52 -0400

On Wednesday, April 25, 2012 01:53:35 PM Murray S. Kucherawy wrote:
> There issue is that we make it a MUST to accept all types listed in a
> registry.  How would an implementation do that?  There's no protocol to
> query the registry for new types, so it can't really be done live.  The
> IESG member is saying we need to explain to people what's involved in
> satisfying that MUST.

We don't really define accept.  If I "250 OK" to accept the message and then 
discard unknown types, that's a win from that perspective.  I probably 
wouldn't do it that way, but that's not inconsistent with the requirement.  I 
don't think it's necessary to have a list of all currently possible values to 
satisfy the requirement to accept all types.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Apr 2012 11:16:47 -0400

> satisfy the requirement to accept all types.

In that case, it's a preposterous MUST requirement.  What that really
means is "accept anything", not "accept all types".

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2012 17:16:18 -0000

>The diff: http://www.blackops.org/~msk/marf-as.html

Looks fine to me.  If I were picking nits I'd suggest that the sentence about
RFC6449 say:

 Further introduction to this topic may be found in [RFC6449], which is
 effectively an Applicability Statement written outside of the IETF and
 so it is unknown whether it would represent IETF consensus.

But it's fine as is.

R's,
John

---

From: Benoit Claise <[email-masked]>
Date: Thu, 26 Apr 2012 01:07:54 +0200

Hi Alessandro,

>    status to selected parts of the former one, while updating it as

I prefer your proposal very much, as it addresses my questions (asked 
part of my review):

    Can you please also a few sentences on how the documents match and
    differ.
    You know, I see rfc6449, published a few months back, and I see this
    document draft-ietf-marf-as-14, which will be published approx. 6
    months
    And I'm wondering, as someone not involved in this WG...
    - Why do we have two almost similar documents?
    - Why RFC 6449 could not be a MARF document?
    - Which one(s) should I read?
    - Are they conflicting? If yes, I guess that draft-ietf-marf-as-14
    take precedence. If no, is draft-ietf-marf-as-14 is superset of RFC
    6449, and RFC 6449 should not be read any longer.
    - etc...

Regards, Benoit.

---

From: SM <[email-masked]>
Date: Wed, 25 Apr 2012 17:08:48 -0700

Hi Benoit,
At 16:07 25-04-2012, Benoit Claise wrote:
>document draft-ietf-marf-as-14, which will be published approx. 6 months

 From RFC 6449:

   "This document may not be modified, and derivative works of it may not
    be created, except to format it for publication as an RFC or to
    translate it into languages other than English."

As a note to John Levine, RFC 6449 clearly says that "it does not 
represent the consensus of the IETF."

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 26 Apr 2012 18:16:10 +0200

Hi Benoit:

> I prefer your proposal very much, as it addresses my questions (asked

Thanks.  The question it in turn raises, however, is whether a crash
course on TS and AS intricacies is a worthy answer to the doubts that
those documents' differing categorizations might generate.

>     You know, I see rfc6449, published a few months back, and I see
>     this document draft-ietf-marf-as-14, which will be published
>     approx. 6 months

In addition to what SM pointed out, let me note that it was a WG
decision to proceed that way.  See e.g.
http://www.ietf.org/mail-archive/web/marf/current/msg00980.html

>     - Which one(s) should I read?

Possibly both, or the AS and the 6449 sections it refers.

>     take precedence. If no, is draft-ietf-marf-as-14 is superset of
>     RFC 6449, and RFC 6449 should not be read any longer.

They're not in conflict.  However, the MAAWG document is clearly
focused on quite large mailbox providers.  Unsolicited reports, that
were relegated to an appendix, have been expanded so as to bring abuse
reporting within the reach of mailbox providers of any size.
Unsolicited reports can be viewed as auto subscriptions to a feedback
loop stream of solicited reports.  RFC 6449's detailed descriptions
apply to the latter topic.

Authentication failure is a somewhat unrelated use case, factored from
other WG documents, that was conveniently added here later.

hth