Subject: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

From: Jim Fenton <[email-masked]>
Date: Thu, 23 May 2019 13:35:47 -0700

In response to Seth Blank's call for issues of 9 May 2019:

DMARC contains what are really two distinct mechanisms, a reporting
mechanism and a policy mechanism. The policy mechanism is largely a
request to the verifier about what to do in the event that a message is
received that does not comply with policy.

There are domains that would like to receive reports, but whose usage of
mail doesn't make it useful to express a policy. Conversely, there are
domains that want to express a policy but aren't interested in reports.
I'd like to advocate that DMARC be split up into two different documents
dealing with reporting and policy separately. If it's useful to have a
separate document that defines what it means to be "DMARC-compliant"
that is referenced by both, that would be OK.

There was a similar situation with MTA-STS which had both a policy and a
reporting mechanism, and that was broken into two standards-track RFCs:
RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport
Security). I consider this to be a relevant precedent.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 23 May 2019 18:52:13 -0400

>that is referenced by both, that would be OK.

Given that we already have one document, I would be very strongly
opposed to this.  It's fine to fix things that are wrong, but trying
to restructure it retroactively will inevitably lead to accidental
incompatibilities.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 May 2019 01:03:36 -0000

In article <[email-masked]>,
>to restructure it retroactively will inevitably lead to accidental

On the other hand, if you want to write separate non-normative
tutorials for the reporting part and the policy part, sure, go ahead.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jim Fenton <[email-masked]>
Date: Thu, 23 May 2019 22:01:18 -0700

> to restructure it retroactively will inevitably lead to accidental

MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you think
might be created.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 May 2019 06:02:50 -0700

> that is referenced by both, that would be OK.

I'm not clear what technical or operational problem you are trying to 
solve.  That is, you seem to be proposing a document split without any 
technical changes.  Yes?

While separating or joining segments of specification makes a 
difference, you haven't described what actual usage issues there have 
been that warrant the effort to split this document.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 May 2019 14:19:16 +0000

>Security). I consider this to be a relevant precedent.

What do you see as the potential advantage of your proposal?

There isn't really a DMARC without expressing a policy.  One may choose to have a policy of none, but it's still there.  In the immortal words of Rush:

"If you choose not to decide
You still have made a choice".

I can see where it might make things a little easier if we were starting from scratch, but we aren't.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2019 10:37:50 -0400

> quite cleanly IMO. I'm not sure what kind of incompatibilities you think

That's because they separated before they were published, so there was 
nothing to be incompatible with.  If I knew what would break when 
reorganizing and rewriting a document into pieces, I could fix it, but 
since I don't, and nobody else does, let's not go there.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 May 2019 10:42:24 -0400

> Security). I consider this to be a relevant precedent.

Hi Jim.

+1.  I agree with the split, if it helps with the focusing of 
completing a Proposed Standard (PS) DKIM-POLICY  framework that 
includes codification for the Author Domain Lookup method, 
clarification for alignment and most important, finally recognizing 
extended 3rd party authorization policies and protocol add-on 
capabilities.

I always felt reporting offered little payoff, added lots of overhead 
to the process, in particular more complex coding requirements, i.e. 
you really don't need JSON, XML, etc layers to do a simple DNS DKIM 
policy check, and there was a high potential for abuse.  In my 2006 
DSAP (DKIM Signature Authorization Protocol) proposal, a reporting 
option was offered but it was made clear it can be abused, so it 
should be limited. 
(https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16)

As you recall, the the past DKIM WG did the same with DKIM when it was 
decided to split the proposed standard's inherent POLICY model (SSP) 
component into two Proposed Standard DKIM Working Group work item 
documents;  DKIM-BASE and DKIM-POLICY. SSP was replaced with ADSP with 
reduced policies, ironically, the 3rd party policies were removed -- 
deemed too complex.  It focused on the principle 1st party domain 
policy, neglecting the 3rd party domain signature and how they should 
be evaluated.

Nonetheless, the split was a success in allowing us to finished 
DKIM-BASE.

But the negatives in the split, as some (including myself) with split 
concerns had predicted might happen, a lost of interest in finishing 
the Proposed Standard DKIM Policy work, coupled with a mis-directed 
attention (wishy future) with reputation methods, eventually, DKIM 
Policy would be abandoned.  I think we lost the interest of many 
policy advocates during this time, in particular when there was a 
resistance towards recognizing the "ADID"  (Author Domain IDentity) 
and not including it as part of the into the DKIM-base "Assessment" 
model.

So can the same happen if DMARC reporting was split from a PS 
DMARC-bis work?

IMO, yes, it could happen. I personally do not have any interest in 
reporting in its current form. I have all received reports gated into 
a NNTP newsgroup for private viewing. I don't see any consistency and 
value from them. So that item that can be done -- more consistency. 
It can discuss XML/JSON viewers, ad-hoc reporting methods to help with 
with labeling patterns.  I believe ARC will also need be part of the 
reporting as well. This can be very complex but also highly subjective 
design ideas. They can be discussed separately and independent of a 
straight forward DKIM author domain policy framework.

Finally, the key issue remains, to this day, over 12-15 years,  the 
dearth of 3rd party authorization concepts.

That is where the fuzziness remains.  To me, this is what DMARC-bis 
has to help finish.  The "Authorized Third Party Signature" (ATPS) 
model need to be recognized and put into the DKIM-POLICY framework, 
allowing it to get endorsed and explored at small to high deployment 
scenarios.  We have allowed the brush back by the "Big Guy" (who can't 
seem to figure it out) deter the possible benefits for all other 
smaller scales.  That is what happen before just to do 1st party and 
ADSP paid the price only to be replaced later with Super ADSP - DMARC. 
  So they were wrong with ADSP, they are probably wrong with ATPS as 
well.  As a smaller organization with a well defined set of domains, 
well-defined network usage of where my domains are used.  Some are 
exclusive, very private, some are used in mailing list, like here. I 
know who is allowed to sign mail on my behalf.  That is all defined in 
published DKIM+ADSP/DMARC+ATPS DNS records.

-- 
HLS

---

From: "Peter M. Goldstein" <[email-masked]>
Date: Fri, 24 May 2019 08:04:28 -0700

Agree with Dave here.

There's no actual usage issues that are being addressed that merit the
split (and the work involved).  If you want to receive reports, but not
have receivers enforce a policy, set 'p=none' and a rua.  If you want to
set a policy but not receive reports, set 'p=<policy>' and an empty rua.  I
don't see why that's considered confusing or problematic.

It's also worth noting that the the precedent isn't an actual operational
precedent yet.  There's only one major receiver who is sending SMTP TLS
reports, and if you follow RFC 8460 to the letter you will not actually
receive them.  Unless you implement the DNS records described in RFC 8461,
you don't get any reports.  As someone who recently dealt with this, and
had a back and forth with the receiver, I can personally attest that this
was very confusing.  The first data point from operational deployment seems
to indicate that splitting RFC 8460/8461 may have been a mistake.  It's
either confusing for the implementing receiver (they are doing something
they shouldn't be doing) or for the domain owner (RFC 8460 isn't enough to
get reports by themselves).

Best,

Peter

On Fri, May 24, 2019 at 6:03 AM Dave Crocker <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Dotzero <[email-masked]>
Date: Fri, 24 May 2019 11:25:55 -0400

Scott expresses it perfectly. +1  There is no compelling reason being given
for the split. Absent a compelling reason, this should not be pursued.

Michael Hammer

On Fri, May 24, 2019 at 10:20 AM Scott Kitterman <[email-masked]>
wrote:

> There isn't really a DMARC without expressing a policy.  One may choose to
> have a policy of none, but it's still there.  In the immortal words of Rush:
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 May 2019 19:16:15 +0200

On Fri 24/May/2019 17:04:28 +0200 Peter M. Goldstein wrote:

> I can personally attest that this [splitting] was very confusing.

+1.  Let's not split, please.

Best
Ale

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 May 2019 10:35:49 -0700

> since I don't, and nobody else does, let's not go there.

I hope this isn't devolving into a "we can't make any changes, because
it might break something" argument. If that's the case, there isn't
anything for IETF to do. But I can understand not wanting to make
changes without seeing clear benefit. Here are the benefits I see:

1. When an MTA product says that it "supports DMARC", does that mean
that it has to support both policy and reporting? RFC 7489 Section 8
seems to say so. Implementation of reporting introduces significant
complexity (aggregation of data into reports, provisions to verify
authorization of external destinations, etc.). This seems like it would
be a significant barrier to support of the policy piece of DMARC. Or
have all of the relevant MTAs already implemented this?

2. Along similar lines, I get confused when I hear that x% of {some set
of domains} has "deployed DMARC". What does that mean? Have they
asserted a particular policy? Are they generating reports? Both? Either?
Perhaps there is a marketing benefit to leaving this fuzzy, but I'm an
engineer and I want to know what the statistics mean.

-Jim

---

From: Brandon Long <[email-masked]>
Date: Fri, 24 May 2019 10:55:36 -0700

> quite cleanly IMO. I'm not sure what kind of incompatibilities you think

Does TLSRPT support both MTA-STS and DANE?  I would think that provides a
logical
reason to separate them that doesn't exist for DMARC.

Brandon

---

From: "Luis Muñoz" <[email-masked]>
Date: Fri, 24 May 2019 11:06:43 -0700

> reason to separate them that doesn't exist for DMARC.

My reading of RFC-8460 says it does:

   Recipient domains may also use the mechanisms defined by MTA-STS
   [RFC8461] or DANE [RFC6698] to publish additional encryption and
   authentication requirements; this document defines a mechanism for
   sending domains that are compatible with MTA-STS or DANE to share
   success and failure statistics with recipient domains.

Best regards

-- 

Luis Muñoz
Director, Registry Operations
____________________________

http://www.uniregistry.link/
400 Spectrum Center Drive
Suite 1660
Irvine, CA 926128

Office +1 949 706 2300 x 4242
[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 May 2019 11:08:26 -0700

On 5/24/19 10:55 AM, Brandon Long wrote:
>
>
> On Thu, May 23, 2019 at 10:01 PM Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > In article <[email-masked]
>     <mailto:[email-masked]>> you
>     write:
> Does TLSRPT support both MTA-STS and DANE?  I would think that
> provides a logical

TLSRPT does support both MTA-STS and DANE, but the same logical reason
probably exists for domains that want to generate or receive reports but
do not want to publish or honor policy assertions. Although I will admit
that publishing an MTA-STS policy is considerably more involved than
with DMARC.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2019 14:25:33 -0400

On Fri, 24 May 2019, Jim Fenton wrote:
> it might break something" argument.

I don't think so, but we also have a tradition of minimizing the changes 
to what's needed.  Look at RFCs 2821 and 5321 for example, where they 
deliberately left the section numbering and most of the language alone and 
fit the changes into the existing structure.

> that it has to support both policy and reporting? ...

> of domains} has "deployed DMARC". What does that mean? ...

Deploying DMARC seems to mean any subset of these:

1a.  Publish a DMARC record
1b.  Publish a DMARC record with a restrictive policy
2a.  Evaluate DMARC status of incoming messages
2b.  Use that status to manage message disposition
3.   Collect reports
4a.  Send aggregate reports
4b.  Send failure reports

It is my impression that most domains that have "deployed DMARC" have done 
1b and 3.  I've done 1a, 2a, 3, and a very small amount of 2b.  Only a few 
sites do 4a and even fewer do 4b.

I'm getting the impression that what we need is a non-normative deployment 
guide, not as part of the spec.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 May 2019 11:39:34 -0700

On 5/24/19 11:25 AM, John R Levine wrote:
> I don't think so, but we also have a tradition of minimizing the
> changes to what's needed.  Look at RFCs 2821 and 5321 for example,
> where they deliberately left the section numbering and most of the
> language alone and fit the changes into the existing structure.

I consider that to be a different situation because both were Standards
Track. This is situation where we are starting with an Informational
RFC, although granted it has more deployment experience than many things
that go to Standards Track.

> It is my impression that most domains that have "deployed DMARC" have
> done 1b and 3.  I've done 1a, 2a, 3, and a very small amount of 2b. 
> Only a few sites do 4a and even fewer do 4b.
>
> I'm getting the impression that what we need is a non-normative
> deployment guide, not as part of the spec.

Although Section 8 of the spec currently has normative requirements for
implementations. Yes, that's different from deployment but having those
requirements to implement something that isn't deployed much (4a
specifically) seems unnecessarily burdensome.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2019 14:42:14 -0400

> specifically) seems unnecessarily burdensome.

Taking out stuff that people don't actually do or marking it as optional 
seems like a reasonable change to the next version of the spec.  But I 
still think a non-normative deployment guide would help people.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 May 2019 13:53:13 -0700

> it might break something" argument.

We are quite a long ways from that.  In fact we are in the "please make 
a case for their being a serious problem that needs fixing" argument, 
combined with the "please explain how the proposed solution will fix the 
serious problem" argument.

> 1. When an MTA product says that it "supports DMARC", does that mean

That's a generic issue that applies to many circumstances.  And since 
there is no standard meaning for "supports x", it has marketing utility, 
not technical.  That's not going to get fixed in this wg.

> that it has to support both policy and reporting? RFC 7489 Section 8

There are multiple opportunities for ambiguity.  Another is:  Does it 
mean publishing or interpreting?

Splitting the documents doesn't solve any of this.

> of domains} has "deployed DMARC". What does that mean? Have they

Ultimately, you are asking marketing questions, not technical ones.

d/

---

From: "John R Levine" <[email-masked]>
Date: 25 May 2019 17:30:33 -0400

> Ultimately, you are asking marketing questions, not technical ones.

Right.  It's easy enough to imagine soemone handing out Official DMARC 
Compliance certificates, but that someone sure wouldn't be the IETF.

Regards,

---

From: Dotzero <[email-masked]>
Date: Sun, 26 May 2019 12:15:16 -0400

See below.

On Fri, May 24, 2019 at 2:39 PM Jim Fenton <[email-masked]> wrote:

> I think you are underestimating the deployment. Many receiving/validating
> organizations have privacy concerns about promiscuously disseminating
> reports. As a result, these organizations limit reports to senders with
> which they have either direct contractual relationships or intermediaries
> with which they have contractual relationships. Personally I would prefer
> to see more and better reporting but I recognize the issues involved. It's
> important to recognize that senders publishing DMARC records are indicating
> their policy preferences to receivers which choose to validate for DMARC.
> Receivers which choose to validate DMARC are not required to provide
> records in response to sender requests. I know that reporting is valuable
> for senders and to the extent possible we should be finding ways to
> encourage and support reporting.
>

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2019 12:53:15 -0400

>> encourage and support reporting.

Still sounds like a deployment guide would be useful, no?

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 May 2019 10:23:42 -0700

> Ultimately, you are asking marketing questions, not technical ones.

OK, so let me ask a technical question: What is the technical 
justification for the requirements in Section 8? For other protocols, 
there are mandatory-to-implement requirements (RFC 6376 section 3.3 for 
example) that exist in order to ensure interoperability between senders 
and receivers. But implementation of DMARC policy and DMARC reporting 
can separately be useful without the other.

Aren't the requirements in Section 8, which effectively say "you need to 
do this and this to call yourself a DMARC implementation" really a 
marketing, not a technical consideration? Does this belong in the spec?

-Jim

---

From: Dilyan Palauzov <[email-masked]>
Date: Mon, 27 May 2019 18:19:57 +0000

Hello Jim,

Do you want to split yourself reporiting and policy and create two  
separate documents, or do you know somebody wiliing to perform the  
separation?  I cannot imagine why shall one want to read and  
understand only reporting or only policy and thus I do net understand  
for which target group will be these separated documents. The current  
documents are suitable to achieve their aim.  (Well, to contradict  
myself, I would like to read and understand all the RFCs, so a single  
RFC containing all current RFCs would be enough, but obviously, I  
cannot read and understand such RFC).

if you implement DMARC filtering on incoming emails you get less spam.

If you implement DMARC filtenig on outgoing emails (say publish policy  
p=reject), you deploy DKIM and then some trust/reputation can be built  
in the DKIM domain, similar to IP reputation, so that your future  
emails are more likely to be delivered, at least in theory.

You do not have interest to name this magic anyhow, you have interest  
on getting less spam and higher deliveribility of your emails.

You do not have to implement section 8 in order to achive the  
aforementioned goals.  When filtering incoming emails, obviously,  
without having to articulate this explicilty, you have to follow  
section 6.6.

To verify that your DMARC works as expected, the reports mentioned in  
section 8 are a nice mean.

You can call your product a DMARC implementation even if it does not  
do DKIM signing/verifying correctly.

Why do my mails for [email-masked] get rejected, unless I send them  
over the MLM?

A propos “Is there any recommendation to send DMARC message-specific  
failure reports FROM:<>”:

* Scott, the purpose of such a recommendation is to have a system,  
which does not cause mail loops, ending with stored copies of 60 000  
sent reports.  If that site published TXT record for  
mail.modernwebsite.pl, it does not ensure that in half an year I will  
not enter another mail loop (half an year ago I had a similar one).

* I do sent now my reports ENV FROM:<> and from the correspondence so  
far neither somebody said that there is such a recommendation already,  
nor that such a recommendadion is bad.  The purpose of the  
<>-recommendation is to prevent others falling in such a mail loop  
trap.  Under this circumstances I put the case under “Collecting DMARC  
issues and nits for DMARC WG phase III - DMARC standardization”.

Regards
   Дилян
----- Message from Jim Fenton <[email-masked]> ---------
    Date: Mon, 27 May 2019 10:23:42 -0700
    From: Jim Fenton <[email-masked]>
Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
      To: Dave Crocker <[email-masked]>, John R Levine <[email-masked]>
      Cc: [email-masked]

> justification for the requirements in Section 8? For other  
> protocols, there are mandatory-to-implement requirements (RFC 6376  
> section 3.3 for example) that exist in order to ensure  
> interoperability between senders and receivers. But implementation  
> of DMARC policy and DMARC reporting can separately be useful without  
> the other.
>
> Aren't the requirements in Section 8, which effectively say "you  
> need to do this and this to call yourself a DMARC implementation"  
> really a marketing, not a technical consideration? Does this belong  
> in the spec?
>
> -Jim
>

----- End message from Jim Fenton <[email-masked]> -----

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2019 14:20:52 -0400

> Aren't the requirements in Section 8, which effectively say "you need to do 
> this and this to call yourself a DMARC implementation" really a marketing, 
> not a technical consideration? Does this belong in the spec?

I agree that it'd makes sense to remove it, or rewrite it to say it's 
about identifying what you're doing, not about compliance.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 May 2019 11:25:14 -0700

> justification for the requirements in Section 8? For other protocols, 

A section like that typically seeks to establish a basis for minimum 
capability of usable implementations.  It sets expectations for 
capabilities and limits.  An amusing bit about this particular one is 
that, in spite of having the word "requirements' in the section title, 
none of the content language is normative.

> can separately be useful without the other.

I don't understand how your last sentence, here, applies to the subject 
Section 8.

> marketing, not a technical consideration? Does this belong in the spec?

"to call yourself" is a perspective neither offered nor implied by the 
section.  A marketing goal might choose to use it for that purpose, but 
there's nothing in the language or substance of the section suggesting 
that use or designed for that use.

d/

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2019 15:13:33 -0400

> capability of usable implementations.  It sets expectations for capabilities 
> and limits.  An amusing bit about this particular one is that, in spite of 
> having the word "requirements' in the section title, none of the content 
> language is normative.

It's certainly confusing.  I understand what the list of items is but I 
don't understand what anyone is supposed to do about them.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 May 2019 12:48:40 -0700

> don't understand what anyone is supposed to do about them.

I'm not claiming it's a wonderful section.  Merely that something like 
it isn't that unusual.  The usual intent is to help people with 
expectations about basic capabilities or capacity.

d/

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 May 2019 13:15:09 -0700

> none of the content language is normative.

I hadn't noticed the lack of normative language in this section. In that 
case I would propose removing it because it does not serve any purpose 
and because it might mislead others who, as I did, misinterpreted the 
word "requirements" in the section title.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 May 2019 13:11:47 -0700

> cannot read and understand such RFC).

Dilyan,

I didn't follow the latter portion of your message entirely, but yes, I 
think I understand the problems that DMARC filtering and reporting are 
intended to solve.

To your initial question, unless a bunch of other people speak up in 
favor of the split I'm proposing, it won't have WG consensus so we don't 
need to consider who does the editorial work involved.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 May 2019 10:39:58 +0200

> 4a.  Send aggregate reports

Nice one!  That analysis should make it to some implementation guide.  I'd
suggest an addition, though:

3a.  Receive and possibly read records
3b.  Collect them

I only do 3a, let me attach an example.  (It also exemplifies 4a, but the
htmlizer is the same.)  I look at sent or received reports occasionally.  They
are automatically deleted after some time.  I never happened to need to process
them as a collection.  If I did, I guess I should reset the accumulated results
when the relevant DMARC/DKIM/SPF records change.  I hope the implementation
guide will explain this.

> It is my impression that most domains that have "deployed DMARC" have done 1b
> and 3.  I've done 1a, 2a, 3, and a very small amount of 2b.  Only a few sites
> do 4a and even fewer do 4b.
> 

+1.  Recall that the current spec is formally non-normative (which might
explain the lack of normative language in Section 8).  If we have to split, I'd
suggest to split into a normative and a non-normative part, where the latter is
an implementation guide.

IMHO: 4a is needed to evaluate the effect of policies, otherwise the protocol
is blind.

Best
Ale
--

---

From: "John R. Levine" <[email-masked]>
Date: 28 May 2019 11:22:11 -0400

> 3a.  Receive and possibly read records

As far as DMARC is concerned, once you've published rua or ruf and receive 
the reports, DMARC is done.  Some people just put them in a mailbox, some 
pick out basic bits and put them in a database, some do elaborate 
analyses, but none of that has anything to do with DMARC compliance.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Wed, 29 May 2019 10:01:11 -0700

One more point on this:

> since I don't, and nobody else does, let's not go there.

You seem to be suggesting that the standards-track DMARCbis should be
different because an informational, non-WG RFC has already been
published. From a process standpoint that's bad; standards-track RFCs
should go through exactly the same process regardless of whether or not
they were previously published as Informational.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 29 May 2019 13:13:23 -0400

> they were previously published as Informational.

As far as I can tell your proposal to break the document in two has 
gotten no support at all.  Can we stop now?

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Wed, 29 May 2019 10:49:29 -0700

> gotten no support at all.  Can we stop now?

This was about a broader process issue and not specifically about
splitting the document into parts (I should have changed the subject
line). But yes, we can stop talking about the document split.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 May 2019 20:19:52 +0200

> they were previously published as Informational.

Albeit rfc7489 is informational, it is meant to be a spec.  So structural
changes to the document, however useful to first-time readers, would be a
nightmare for those who have already implemented DMARC and are checking what
has changed.  It would also disrupt many references, thereby invalidating a
large part of the literature.

A new companion rfc (or a new appendix, or a rewriting of Section 8) meant as
an implementation guide could host discussions about the points 1a... 4b listed
upthread.  It should recount the most useful tips we collected thus far, rather
than trying to establish normative duties, IMHO.

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 May 2019 17:54:31 -0400

> gotten no support at all.  Can we stop now?

"No support at all?"   For the record, I support the "split."  But I 
won't care it is remains.  I just think it will complicate a 
specification and extend the future work of completing a DKIM Policy 
Model proposed standard which is in need of a tremendous amount of work.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 May 2019 11:13:37 -0700

> gotten no support at all.  Can we stop now?

What's on topic for the group and what isn't is the purview of the
co-chairs and the charter.  Let's please not stifle discussions before they
die on their own absent chair action to the contrary.

-MSK, from the floor