Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Feb 2020 10:47:45 -0800

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[email-masked]> wrote:

> Nothing I've worked on at the IETF with such a label is something I would
> necessarily stand behind as Internet-scalable.
>
> Such as?
>

RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment
that never even ran.  Implementations shipped, but its use on the open
Internet was never detected or reported.  And I had my doubts about the
scalability of the second DNS check that was added to it, but it didn't
seem like it could go forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something
can be.

>
> But I would probably expect something at Informational probably to scale,
> and anything with "Standard" in it certainly to scale.
>
> Laying any general expectation on an IETF Informational RFC would be a
> mistake, because there is so much variety in their content and intent.
>

Why would the expectations for Experimental be higher than for
Informational?  LMTP is Informational, and it certainly needs to succeed.

> So: Can you propose any sort of specific restructuring of the document or
> the experiment that achieves the same goal as the current version while
> also resolving your concerns?
>
> I'm pretty sure I've raised fundamental concerns about this work and that
> those concerns have not been addressed.  The simple summary is that the way
> to restructure this work is to go back to first principles.  But there
> doesn't seem to be any interest in having that sort of discussion.
>
I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of this
back to first principles and separate DMARC from the determination of
Organizational Domain (i.e., make them separate documents) before PSD can
proceed.  Since that will take months, I've proposed a compromise, because
I don't think that's strictly necessary to allow the data collection work
to proceed.  The proposed compromise, then, is to do the work in hand, then
rip the experiment down and apply whatever we learn from it to standards
track DMARC, which is the next milestone.  That will include the separation
of function you proposed, because we agree it's an improvement.  I believe
the set of likely participants in the experiment are present on the list,
and it can be made clear to them that they should have no expectation of
the mechanism it describes surviving past the termination of the
experiment.  So the path forward here comes down to whether the working
group achieves consensus on that compromise, or whether the asserted risk
of the experiment's structure leaking into the permanent deployed base
warrants shutting it down before it starts.

Now, to the working group as a whole:

The chairs note that we have a duly and properly completed WGLC in hand.
Still, Dave's concerns have validity, so they need to be considered by the
working group.  Since we need to do *something*, we are now putting the
question back to the working group, and we need to see some answers.  The
chairs will not accept hearsay replies or opinions, or expressions of
needing this work but not knowing how to engage; you either give your
feedback on the list or privately to the chairs or Area Directors, or you
are along for whatever ride results.  Please indicate, as soon as possible,
where your support lies given the above.  We're not going to let this go
additional months (probably not even weeks) without progress in some
direction.

I will also say for the record that we don't find compelling the assertion
that resources will not be dedicated to the experiment absent a document in
the RFC Editor queue.  That constraint is fully external to the IETF, and
it will carry no weight in the decision made here.  It should indeed be
possible to run an experiment based on a document in any state at all.
We're entertaining publication not because it must happen, but because that
action (currently) has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected to fail
are not generally what the IETF produces.  I would quibble some with that
wording: The working group doesn't expect the experiment to "fail", but
rather expects it to be ephemeral.  Were we to refer to chapter-and-verse,
there's nothing in RFC2026 (which defines "Experimental" as a document
status) that precludes what the working group appears to be trying to do
here.  As for whether the IETF generally should produce an Experimental
document describing something ephemeral, I would claim that a working group
or its chairs are below the pay grade where authoritative claims like those
are made; it's the kind of thing about which the IESG makes proclamations.
Accordingly, I've Cc'd our current Area Director to see what he thinks
might happen if we were to send this up, and give him a chance to provide
guidance in case that's the decision (but we won't wait long for that
either).

> The real challenge for most IETF specs is community engagement, not
>> engineering adequacy.
>>
>
> Interestingly I would claim we have clearly achieved the former here,
> though obviously not the latter.
>
> My sense is -- as has become common in the IETF -- an extremely small core
> of folk interesting in promoting this work, rather than extensive community
> interest.
>
That's probably true, but by that argument we should just terminate most of
the email-related working groups because the critical mass we can get today
is a fraction of what it used to be.

Those sorts of existential questions can't be answered at this level,
however.  I would claim the working group was chartered with the
understanding that the participation here won't be like it was for, say,
DKIM, or DRUMS, etc.  We're not in a position to fix that here.  We have a
job to do, and we need to get moving again.

-MSK

---

From: Ian Levy <[email-masked]>
Date: Mon, 3 Feb 2020 19:51:48 +0000

> I believe the set of likely participants in the experiment
> are present on the list, and it can be made clear to
> them that they should have no expectation of the
> mechanism it describes surviving past the termination
> of the experiment.

I believe I represent one of those participants and I’m happy with Murray’s caution. Experiments will give us data that helps us make better solutions in the future. If those solutions look like the current draft then great. If they don’t then we’ll be changing them based on data and experience.

Surely that’s a good outcome for all??

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]

Staff officer : Tracy, [email-masked] or 07468 837625
Assistant : Rose, [email-masked]

Pronouns : he/him
(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)
________________________________
From: dmarc <[email-masked]> on behalf of Murray S. Kucherawy <[email-masked]>
Sent: Monday, February 3, 2020 6:47:45 PM
To: Dave Crocker <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>; Alexey Melnikov <[email-masked]>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:
Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable.

Such as?

RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment that never even ran.  Implementations shipped, but its use on the open Internet was never detected or reported.  And I had my doubts about the scalability of the second DNS check that was added to it, but it didn't seem like it could go forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something can be.

But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.

Why would the expectations for Experimental be higher than for Informational?  LMTP is Informational, and it certainly needs to succeed.
So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?

I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed.  The simple summary is that the way to restructure this work is to go back to first principles.  But there doesn't seem to be any interest in having that sort of discussion.

Your position as I recall is that we have no choice but to take all of this back to first principles and separate DMARC from the determination of Organizational Domain (i.e., make them separate documents) before PSD can proceed.  Since that will take months, I've proposed a compromise, because I don't think that's strictly necessary to allow the data collection work to proceed.  The proposed compromise, then, is to do the work in hand, then rip the experiment down and apply whatever we learn from it to standards track DMARC, which is the next milestone.  That will include the separation of function you proposed, because we agree it's an improvement.  I believe the set of likely participants in the experiment are present on the list, and it can be made clear to them that they should have no expectation of the mechanism it describes surviving past the termination of the experiment.  So the path forward here comes down to whether the working group achieves consensus on that compromise, or whether the asserted risk of the experiment's structure leaking into the permanent deployed base warrants shutting it down before it starts.

The chairs note that we have a duly and properly completed WGLC in hand.  Still, Dave's concerns have validity, so they need to be considered by the working group.  Since we need to do *something*, we are now putting the question back to the working group, and we need to see some answers.  The chairs will not accept hearsay replies or opinions, or expressions of needing this work but not knowing how to engage; you either give your feedback on the list or privately to the chairs or Area Directors, or you are along for whatever ride results.  Please indicate, as soon as possible, where your support lies given the above.  We're not going to let this go additional months (probably not even weeks) without progress in some direction.

I will also say for the record that we don't find compelling the assertion that resources will not be dedicated to the experiment absent a document in the RFC Editor queue.  That constraint is fully external to the IETF, and it will carry no weight in the decision made here.  It should indeed be possible to run an experiment based on a document in any state at all.  We're entertaining publication not because it must happen, but because that action (currently) has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected to fail are not generally what the IETF produces.  I would quibble some with that wording: The working group doesn't expect the experiment to "fail", but rather expects it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in RFC2026 (which defines "Experimental" as a document status) that precludes what the working group appears to be trying to do here.  As for whether the IETF generally should produce an Experimental document describing something ephemeral, I would claim that a working group or its chairs are below the pay grade where authoritative claims like those are made; it's the kind of thing about which the IESG makes proclamations.  Accordingly, I've Cc'd our current Area Director to see what he thinks might happen if we were to send this up, and give him a chance to provide guidance in case that's the decision (but we won't wait long for that either).

Interestingly I would claim we have clearly achieved the former here, though obviously not the latter.

My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.

That's probably true, but by that argument we should just terminate most of the email-related working groups because the critical mass we can get today is a fraction of what it used to be.

Those sorts of existential questions can't be answered at this level, however.  I would claim the working group was chartered with the understanding that the participation here won't be like it was for, say, DKIM, or DRUMS, etc.  We're not in a position to fix that here.  We have a job to do, and we need to get moving again.

-MSK
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Craig Schwartz <[email-masked]>
Date: Mon, 3 Feb 2020 19:21:25 -0500

Hi Murray,

<<<The chairs will not accept hearsay replies or opinions, or expressions
of needing this work but not knowing how to engage; you either give your
feedback on the list or privately to the chairs or Area Directors, or you
are along for whatever ride results.  Please indicate, as soon as possible,
where your support lies given the above.>>>

In my capacity as managing director of fTLD Registry Services (fTLD),
registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would
provide invaluable threat intelligence to domain registrants and to TLD
administrators like ourselves for NXDOMAINs. PSD has tremendous value to
specialized TLDs including, but not limited to, .BRANDS, community-based
domains, high-security domains, governments, etc. and as such I believe PSD
should proceed. I’ve previously posted to this list expressing this view
and while fTLD cannot participate in experimentation due to a prohibition
by ICANN, we remain committed to supporting and seeing this work continue.

Sincerely,

Craig

*--*
Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz
www.fTLD.com

On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Your position as I recall is that we have no choice but to take all of
> this back to first principles and separate DMARC from the determination of
> Dave also made an additional observation, that experiments expected to
> fail are not generally what the IETF produces.  I would quibble some with
> that wording: The working group doesn't expect the experiment to "fail",
> but rather expects it to be ephemeral.  Were we to refer to
> chapter-and-verse, there's nothing in RFC2026 (which defines "Experimental"
> as a document status) that precludes what the working group appears to be
> trying to do here.  As for whether the IETF generally should produce an
> Experimental document describing something ephemeral, I would claim that a
> working group or its chairs are below the pay grade where authoritative
> claims like those are made; it's the kind of thing about which the IESG
> makes proclamations.  Accordingly, I've Cc'd our current Area Director to
> see what he thinks might happen if we were to send this up, and give him a
> chance to provide guidance in case that's the decision (but we won't wait
> long for that either).
>
>
>> My sense is -- as has become common in the IETF -- an extremely small
>> core of folk interesting in promoting this work, rather than extensive
>> community interest.
>>
> That's probably true, but by that argument we should just terminate most
> of the email-related working groups because the critical mass we can get
> today is a fraction of what it used to be.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Feb 2020 19:08:06 -0800

> by ICANN, we remain committed to supporting and seeing this work continue.

Craig,

Thanks for this, and for one other person that sent to the chairs privately
(it was a list non-member caught in moderation, nothing secret).

To be clear, however: I think the working group mailing list archive has
enough of a record that participants think the experiment will be useful or
even critical to the evolution of DMARC, though people are of course
welcome to affirm that support for the record.  The question being put,
however, goes to the form of the experiment and the current form of DMARC
as a protocol with respect to determining Organizational Domains, and
whether there are indeed risks to the deployed infrastructure that the
experiment could become permanent.  That's the meaty stuff that would
really help to move this along.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 10:30:41 -0500

> additional months (probably not even weeks) without progress in some

Personally, I think Dave is wrong.  I think he's given an assertion, but 
nothing beyond that.  Given that DMARC has been successfully deployed at scale 
depending on a list (PSL), I believe that's an adequate existence proof that 
Dave's assertion that anything depending on a list can't scale is not correct.

Dave's claim that the IETF hasn't done anything depending on a list may or may 
not be correct, I don't know, but that's not a technical point.  If the IETF 
was stopped by "we haven't done this before", we wouldn't have much of an 
Internet today.

That isn't to argue using the PSL to find the org domain is a technically clean 
solution.  It's not.  It's only less horrible than the alternatives.

> action (currently) has consensus, and it's our job to act on consensus.

I think the IETF tells external organizations not to use I-Ds [1], so I don't 
really understand this point, but I don't think it affects consensus much.
> guidance in case that's the decision (but we won't wait long for that

It won't surprise you to find that I support publishing the draft substantially 
as is.  I believe there are some open questions described in the experimental 
portions of the draft that will take some operational experience to evaluate 
and having a stable reference will be useful for that purpose.

As a side note, I don't think this is anywhere near the most extreme 
experimental document that IETF has considered for publication.  The Sender ID 
RFCs conflicted with current Internet Standards and were still published even 
after an appeal on that point.  Having just re-read the IAB response to that 
appeal [2], particularly Section 3, I'm even more convinced that the DMARC PSD 
draft is well within the realm of what's appropriate for an experimental RFC.

Scott K

[1] https://ietf.org/standards/ids/
[2] https://www.iab.org/appeals/2006-2/iab-response-to-appeal-from-julian-mehnle-2-march-2006/

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 4 Feb 2020 09:39:09 -0800

I support publishing the I-D as confirmed in the WGLC with (perhaps) some
additional caveats regarding the ephemerality of the Experiment as deemed
necessary by the chairs.

Given the expected duration of the experiment (at least a year to collect
some useful data, if not 2-3 years), I also support unblocking the other
work in this WG since we ought not wait for this experiment to "conclude"
(whatever that means) before proceeding on other work items.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 4 Feb 2020 19:27:18 +0100

On Mon 03/Feb/2020 19:47:45 +0100 Murray S. Kucherawy wrote:
> chairs will not accept hearsay replies or opinions, or expressions of needing
> this work but not knowing how to engage; you either give your feedback on the
> list or privately to the chairs or Area Directors, or you are along for
> whatever ride results.  Please indicate, as soon as possible, where your
> support lies given the above.  We're not going to let this go additional months
> (probably not even weeks) without progress in some direction.

I support publishing draft-ietf-dmarc-psd as is.

As I wrote already, I appreciate Dave's narration and think it can lead to a
better overall statement of DMARC.  However, I don't think it suggests any
practical software technique that may improve [PSD]DMARC implementations in the
short term.

> I will also say for the record that we don't find compelling the assertion that
> resources will not be dedicated to the experiment absent a document in the RFC
> Editor queue.  That constraint is fully external to the IETF, and it will carry
> no weight in the decision made here.  It should indeed be possible to run an
> experiment based on a document in any state at all.  We're entertaining
> publication not because it must happen, but because that action (currently) has
> consensus, and it's our job to act on consensus.

There are a number of ICANN liaisons mentioned in IETF website[*].  I think it
is their, or at least some of them's, duty to inform the relevant ICANN
authority about the experiment, so that they can allow it to proceed, as soon
as draft-ietf-dmarc-psd enters the RFC Editor queue.  Will Area Directors
please advise them?

NOTE: The provision to publish _dmarc resource records, or whatever selection
of registered underscored node names[†], under selected global TLDs is *not* to
be considered ephemeral.

[*] https://ietf.org/about/liaisons/
[†]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

> Dave also made an additional observation, that experiments expected to fail are
> not generally what the IETF produces.  I would quibble some with that wording:
> The working group doesn't expect the experiment to "fail", but rather expects
> it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in
> RFC2026 (which defines "Experimental" as a document status) that precludes what
> the working group appears to be trying to do here.  As for whether the IETF
> generally should produce an Experimental document describing something
> ephemeral, I would claim that a working group or its chairs are below the pay
> grade where authoritative claims like those are made; it's the kind of thing
> about which the IESG makes proclamations.  Accordingly, I've Cc'd our current
> Area Director to see what he thinks might happen if we were to send this up,
> and give him a chance to provide guidance in case that's the decision (but we
> won't wait long for that either).

I don't expect the experiment to fail.

What seems to me to be ephemeral is its providing for three different
services[‡] to determine which TLDs deserve an extra DNS lookup.  The
experiment will hopefully determine which one(s) are fit.

[‡] https://psddmarc.org/

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 14:49:03 -0500

> (whatever that means) before proceeding on other work items.

I don't see any reason the other WG items can't proceed in parallel with the 
experiment.  I believe the changes to DMARC to bring it to IETF standards, 
particularly the need for an alternative to the PSL, will take significant 
effort to achieve.  As a result, I think there's little risk that results from 
the experiment will end up being a critical path item for any WG effort.

Scott K

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Feb 2020 15:25:06 -0500

I do not support publishing draft-ietf-dmarc-psd as is. Running code and
rough consensus.

I, as were a few others on the list, was part of the private effort that
eventually became the "DMARC team". I point out that until DMARC was
published openly, the experiment had absolutely zero impact on others and
the Internet at large. It was a closed system. Subsequent to publication
(not originally as an I-D), some receivers did take steps that some
considered coercive towards senders, but that was beyond the specification
itself. At a subsequent point, some (large) sender domains published DMARC
policies that were painful for both intermediaries as well as users with
accounts at those domains but which sent mail from other origins.

Someone pointed to Sender-ID as an example experiment. A very poor example
to choose. It was broken from the start. As an aside, I kept sending email
to the folks at Microsoft using @Microsoft.com email addresses by using
"Sender" to game PRA to get a neutral". Furthermore, it dragooned senders
who had no intention of participating in the experiment by reusing their
published SPF records in a manner they did not intend them to be used. I
also point out how long it took to put a stake in the heart of Sender-ID.
And yet even today we can find Sender-ID records littering the Internet and
even a few places doing Sender-ID checks. For some definition of "We", we
are good at additions and modifications but poor at deletes.

I am not against experiments, but having reread the entire thread starting
from Dave's post in August, I believe his concerns are valid. My question
to the chairs and the group as a whole is whether an experiment can be
constructed that is valid and useful without "comingling" PSD issues and
concerns with the core of DMARC at scale? That is, the group that is
seriously interested does their experiment amongst themselves to produce
data that supports and justifies such changes in the wild.

"Be conservative in what you do, be liberal in what you accept from others.
..."

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 15:39:38 -0500

> are good at additions and modifications but poor at deletes.

That was me.  I agree it was a horrible idea.  The point wasn't that Sender ID 
was great, it wasn't.  The point was that the AIB considered it reasonable as 
an experiment.  I think this is far less risky than that was.  I was trying to 
respond to the idea what the IETF doesn't support experiments where there are 
technical concerns about the nature of the technology.  The AIB's position, as 
I read it, was that such experiments are fine and if the IESG has concerns, 
they should add a note to document.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 15:44:00 -0500

> data that supports and justifies such changes in the wild.

I think the draft as written works as you suggest.  I think Dave's concerns 
are really about DMARC (or at least 99.6% about DMARC) and not significantly 
related to this addition.  As designed, the experiment is self-contained:

For senders, it only affects PSDs that have been listed as participants.

For receivers, it only affects receivers that choose to deploy code to do the 
additional check related to PSD DMARC.

As far as I can determine, there is zero impact on anyone else.

We have running code.  I'll leave it to the chairs to evaluate the consensus.

Scott K

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Feb 2020 15:46:41 -0500

> they should add a note to document.

At the risk of offending some, politics was the elephant in the room on
Sender-ID and SPF both ending up being designated as experimental.

Michael Hammer

---

From: Andrew Kennedy <[email-masked]>
Date: Tue, 4 Feb 2020 15:49:03 -0500

Scott--I agree whole-heartedly.  One has to wonder if delaying or impeding
advancement of this I-D, because of an external dependency that appears
unlikely to be resolved in a timely fashion, is making the perfect the
enemy of the good.  This group has much accomplish in a time frame quite
possibly measured in years and that work can and should be done in parallel
to competing IETF equities.  The stated risk, as I understand it, appears
small as it is constrained by the experiment and resolvable in future
drafts (and implementations).

-Andrew

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Feb 2020 15:50:12 -0500

> related to this addition.  As designed, the experiment is self-contained:
And those are my concerns as well. I would rather see DMARCbis go forward

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 16:20:05 -0500

On Tuesday, February 4, 2020 3:50:12 PM EST Dotzero wrote:
> > > I am not against experiments, but having reread the entire thread
> > 
> > starting
> > 

I agree on DMARCbis.  I don't think advancing this draft has a significant 
effect on that.  Worst case, if DMARCbis is done before we can reach any 
conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in it.

I don't see anything about PSD DMARC being inherently on the critical path for 
DMARCbis.  I suspect the current major obstacle to DMARCbis is that the 
question of how to take the PSL out of the equation is unsolved, despite one 
IETF WG that was supposed to be dedicated to the question.

I don't think not publishing PSD DMARC helps move DMARCbis forward, so I think 
it's a false choice.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2020 13:20:40 -0800

On Tue, Feb 4, 2020 at 12:25 PM Dotzero <[email-masked]> wrote:

> from Dave's post in August, I believe his concerns are valid.
>

I want to say again that I make no assertion that any of Dave's claims are
invalid.  The main thing I want us to discuss is whether any of them rise
to the level of halting PSD's movement through the process versus finding a
way to do all of it in parallel, accepting the risks being identified.
Fixing everything first will be extremely time-consuming, but it is a
possible course of action.

My question to the chairs and the group as a whole is whether an experiment
> can be constructed that is valid and useful without "comingling" PSD issues
> and concerns with the core of DMARC at scale? That is, the group that is

Yes, that is the question.  And the working group can still legitimately
conclude that it wants to advance this document before conducting that
experiment.  As you said, rough consensus.

I would remind everyone, however, that this document still needs to pass a
two week IETF-wide Last Call, appropriate directorate reviews, and IESG
review before it can be sent to the RFC editor queue, where again it will
wait for a while.  Assuming we have consensus to proceed in spite of what
Dave and now Mike are saying, we're still at least a month or two from
publication.  That seems a long time to wait before starting the experiment
and collecting data.  Are we sure we want to serialize everything this way?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2020 13:26:30 -0800

> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in

I think we've always been assuming that PSD DMARC would be input to
DMARCbis, so we were planning to start the latter but not close it until
the former was completed.  This is the first time I've seen a different
suggestion.

I'd love to hear more opinions about ordering of the work here.  This seems
like an ideal time to review and update our milestones.

I don't see anything about PSD DMARC being inherently on the critical path
> for

I think what Dave proposed about PSL separation from DMARC is entirely
appropriate and pragmatic, and in fact probably easy enough: DMARC is
changed so that it says the organizational domain is determined using some
process [currently] external to DMARC, and then a second document explains
how that process is accomplished using the PSL (and/or PSD, depending on
when the experiment result comes in).  That's a fairly simple edit overall,
and is actually probably minor and non-controversial compared to some of
the other surgery that I believe is in the queue.

Seth, our illustrious WG secretary, has been compiling that list, and
perhaps can give us some idea where it stands?

-MSK

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Feb 2020 16:43:55 -0500

On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy <[email-masked]>
wrote:

> <snippage>
This would go a long way to alleviating my concerns.

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Feb 2020 17:05:24 -0500

> the former was completed.  This is the first time I've seen a different

I think DMARCbis will take long enough that that is how things will work out, 
but if there's working group consensus to eventually proceed without it 
because it's not ready, that may well be a reasonable course of action.  
Proceeding with DMARC PSD doesn't tie the working group's hands.  I agree 
that's been the plan, but if the situation changes (and DMARCbis is ready, but 
PSD DMARC isn't ready to be included) then we can change it.

It does occur to me that a more relaxed approach to the question of if PSD 
DMARC will be included in the working group DMARCbis deliverable would be much 
easier to sustain if there was a stable reference for it (i.e. we publish the 
draft).

> like an ideal time to review and update our milestones.

I think it's not predictable when DMARCbis will be mostly complete and it's 
also hard to predict how long it will take to resolve the open questions in 
the experiment.  They can run in parallel for some period of time and we can 
make a decision when there's one to make.  There's none needed now.

> the other surgery that I believe is in the queue.

That's exactly the approach PSD DMARC takes about organizational domain, so 
I'm even more confused how that's problematic for PSD DMARC but doing the 
exact same thing solves the problem for DMARC?

I also don't see how that actually helps.  It seems to be something along the 
lines of claiming DMARC no longer relies on the PSL, but telling people to pay 
no attention to the man behind the curtain [1].

Scott K

> perhaps can give us some idea where it stands?

[1] https://www.shmoop.com/quotes/pay-no-attention-man-behind-the-curtain.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Feb 2020 15:36:24 -0800

> This would go a long way to alleviating my concerns.

The question to you, then, is: Is it the case that this MUST be done
*first*?

-MSK

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Feb 2020 18:43:27 -0500

> The question to you, then, is: Is it the case that this MUST be done

Dropping IETF "MUST" on me are you? "Alex, I'll take something between
"MUST" and "SHOULD" for $200".

Let me cogitate on this a bit.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2020 02:33:43 -0000

In article <CAL0qLwYn_=751b---rqFmiPa9RcdAPBtCEowH1AO1=[email-masked]>,
Murray S. Kucherawy  <[email-masked]> wrote:
>>> when the experiment result comes in).

The current DMARC spec essentially says the first part, that you have to find
the org domain but waves its hands about how.

I really would not want to make the PSL a requirement for any spec.
The people who maintain it say in large letters on their web site 
not to use it for any new applications.

There's no technical bar to doing something else.  I have running code
for a DNS lookup technique that does everything the PSL does without a
tree walk at https://github.com/jrlevine/bound

The problem is that we seem unable to agree on any PSL or not-PSL like thing.

R's,
John
-- 
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: Dave Crocker <[email-masked]>
Date: Tue, 4 Feb 2020 19:20:14 -0800

(I am trying to formulate a response on the higher-level technical and 
process issues under consideration, but decided to respond now on these 
particulars, since they are more focused...)

On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
>>     Nothing I've worked on at the IETF with such a label is something
>>     I would necessarily stand behind as Internet-scalable.
>
>     Such as?
>
>
> RFC 6541 comes to mind.  To the best of my knowledge, it's an 
> experiment that never even ran.

I don't recall that scaling limitation was an embedded and acknowledged 
fact about that spec. And with a quick scan I don't see anything about 
that in the document.

There is a difference between having some folk be critical of an 
experiment, versus have its non-scalability be an admitted limit to its 
future.  That is, you or I or whoever might know a spec sucks and can't 
succeed, but that's different from having the formal process declare 
that an experiment is /intended/ not to scale, which seems to be the 
case here.

> Implementations shipped, but its use on the open Internet was never 
> detected or reported.  And I had my doubts about the scalability of 
> the second DNS check that was added to it, but it didn't seem like it 
> could go forward without.
>

There is a reasonable argument to be made that little about /any/ 
security spec actually scales well, but that's such a cheap shot, I 
wouldn't dream of taking it.

However, yeah, "to find out how bad including hash parameters will be" 
does seem to provide an existence proof for using IETF Experimental to 
bench-test something rather than as a gateway to standard for that 
something.  sigh.

>>     But I would probably expect something at Informational probably
>>     to scale, and anything with "Standard" in it certainly to scale.
>     Laying any general expectation on an IETF Informational RFC would
>     be a mistake, because there is so much variety in their content
>     and intent.
>
>

As a rule -- or certainly a solid pattern -- Experimental means that the 
document wants to be standards track or BCP but needs some vetting 
before being permitted that honor.  Informational docs don't have an 
expectation of making it to standards track.

>>     So: Can you propose any sort of specific restructuring of the
>>     document or the experiment that achieves the same goal as the
>>     current version while also resolving your concerns?
>
>     I'm pretty sure I've raised fundamental concerns about this work
>     and that those concerns have not been addressed.  The simple
>     summary is that the way to restructure this work is to go back to
>     first principles.  But there doesn't seem to be any interest in
>     having that sort of discussion.
>
> this back to first principles and separate DMARC from the 
> determination of Organizational Domain (i.e., make them separate 
> documents) before PSD can proceed.

Unfortunately, that's accurate. At the least, I'd expect to see 
thoughtful responses and some breadth of support for those responses, 
countering the fundamental concerns I expressed. I don't recall seeing 
responses with such substance.

(One of the challenges for me, in trying to formulate the 'thoughtful' 
response I'm considering is to provide/repeat a concise summary of those 
fundamental concerns.  As I recall they were both architectural and 
operational.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Feb 2020 01:13:02 -0500

On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:
> > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[email-masked]
> > 
> > <mailto:[email-masked]>> wrote:

This claim seems to me to be unrelated to anything in the draft.  Would you 
please point to where you found this?

> expectation of making it to standards track.

Would you withdraw your objections if we made this informational?

> fundamental concerns.  As I recall they were both architectural and

Help me understand.

Currently the proposal is:

PSD DMARC defines PSD relative to org domain and points to DMARC for how one 
finds org domain (no PSL reference in the PSD DMARC draft - there have been at 
times, but there aren't now).

You find this unacceptable, as I understand it.  What you think we should do is 
first split the DMARC spec into two so that:

PSD DMARC defines PSD relative to org domain and points to DMARCbis for how one 
finds org domain and DMARCbis points to a new spec that explains how to use the 
PSL to find the org domain (or some other method if it's agreed).

You find this acceptable, as I understand it.

Assuming that's correct, please help me understand what PSD DMARC is affected 
at all.  All it does is consume the org domain however DMARC/DMARCbis choose 
to define it.  I don't see as it makes a difference from a PSD DMARC 
perspective.

I get that you want to fix the architectural warts in DMARC and I don't 
disagree with you about working on that.  Where I get lost is how PSD DMARC 
has anything to do with it.  PSD DMARC could be done first, in parallel, or 
after the DMARC architectural work.  It would have no impact on that work.

I would like to understand your position, but I don't, so please help me out 
here.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 4 Feb 2020 22:29:24 -0800

On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman <[email-masked]>
wrote:

>
> Assuming that's correct, please help me understand what PSD DMARC is
> affected at all.  All it does is consume the org domain however
> DMARC/DMARCbis choose to define it.  I don't see as it makes a difference
> from a PSD DMARC perspective.
>
> I would like to understand your position, but I don't, so please help me
> out here.
>

Scott,

Thank you for expressing this so clearly. This is exactly the issue that
I've been trying to understand in this series of conversations. It seems
like the PSD proposal has been being used as leverage to have an (almost)
entirely separate discussion about DMARCbis.

--Kurt

---

From: Craig Schwartz <[email-masked]>
Date: Wed, 5 Feb 2020 05:59:11 -0500

Murray,

Notwithstanding the extensive commentary on this list in the last 24 hours,
you wrote the following so let me share some thoughts.

<<<To be clear, however: I think the working group mailing list archive has
enough of a record that participants think the experiment will be useful or
even critical to the evolution of DMARC, though people are of course
welcome to affirm that support for the record.  The question being put,
however, goes to the form of the experiment and the current form of DMARC
as a protocol with respect to determining Organizational Domains, and
whether there are indeed risks to the deployed infrastructure that the
experiment could become permanent.  That's the meaty stuff that would
really help to move this along.>>>

First, while I know you've said the needs of external actors won't
weigh on your
decision about moving forward, I would like to mention that having a stable
reference for PSD DMARC will help us with working towards policy changes
that would allow us to participate in this experiment.  It may not be important
to the WG Chairs' decision on the draft, but there are stakeholders for
whom it is important.

Second, I have consulted with my technical advisors and our conclusion is
that the risks to deployed infrastructure if this experiment becomes
permanent are negligible.  Currently the PSL has 8,818 non-comment
entries.  For PSD DMARC, we have 4.  We don't believe adding a list that's
.04% as long as the one that is currently being used successfully for DMARC
is an issue at all. Additionally, we believe that the use of this list to
constrain when PSD DMARC lookups will need to occur provides a very useful
limit on the impacts to DNS
(not that we would expect them to be significant regardless).

Finally, if the DMARC working group is successful in updating DMARC not to
use the PSL, then PSD DMARC would naturally evolve to use that solution
(PSD is currently defined relative to org domain, so if the method for
finding org domain changes, PSD DMARC will use it without any change
needed).  As a result, to the extent the use of lists like the PSL is a
problem, PSD DMARC is already ready to take advantage of whatever solution
the IETF develops.

In short, we've reviewed this and see many advantages to proceeding and
none for not.

Craig

*--*
Craig Schwartz
Managing Director

On Mon, Feb 3, 2020 at 10:08 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Thanks for this, and for one other person that sent to the chairs
> privately (it was a list non-member caught in moderation, nothing secret).
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Feb 2020 06:41:49 -0800

> please point to where you found this?

Murray's 12/3 email:

"I don't think it's based entirely on naivety.  I think there's a 
healthy dose of feeling that the experiment as it's currently designed 
couldn't possibly scale to "the entire domain namespace" and/or "all 
servers on the Internet", so in that sense from where I sit there's a 
built in safeguard against this becoming a permanent wart."

> Would you withdraw your objections if we made this informational?

It would eliminate my concerns about this being Experimental, of 
course.  With an equal 'of course', it would not affect the technical 
concerns.

> Help me understand.

I'll try with the other note I'm considering. However my intent for that 
note is as a summary, not as offering some new material.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Feb 2020 06:59:00 -0800

On 2/5/2020 6:40 AM, Dave Crocker wrote:
> I'll try with the

no idea why my text got truncated.

what I typed was: I'll try with the other response I'm considering.

d/

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Wed, 5 Feb 2020 23:11:35 +0000

On Tuesday, February 04, 2020 3:44 PM Scott Kitterman wrote:
> As designed, the experiment is self-contained: For senders, it only affects
> PSDs that have been listed as participants. For receivers, it only affects
> receivers that choose to deploy code to do the additional check related to 
> PSD DMARC. As far as I can determine, there is zero impact on anyone else.

On Wednesday, February 05, 2020 5:59 AM Craig Schwartz wrote:
> permanent are negligible.

As both Craig and Scott pointed out, this experiment will only impact senders 
and receivers who opt-in to participating and has minimal risks to deployed 
infrastructure, so there shouldn’t be an issue there. For scalability, it may 
or may not scale as is, but the experiment has limited risk and should provide 
data on scalability or other issues, and so would be a good experiment to 
provide input into making DMARC better. 

On Wednesday, February 05, 2020 5:59 AM Craig Schwartz wrote:
> use the PSL, then PSD DMARC would naturally evolve to use that solution (PSD
> is currently defined relative to org domain, so if the method for finding org
> domain changes, PSD DMARC will use it without any change needed).  As a 
> result, to the extent the use of lists like the PSL is a problem, PSD DMARC 
> is already ready to take advantage of whatever solution the IETF develops.

For the question related to the PSL and determining the Organizational Domain, 
I think Scott, Kurt, and Craig established this is not an issue for this 
experiment since that issue lies with DMARC itself and so it does not need to 
be addressed in PSD DMARC or for this experiment to proceed. 

On Tuesday, February 4, 2020 3:49 PM Andrew Kennedy wrote:
> One has to wonder if delaying or impeding advancement of this I-D, because
> of an external dependency that appears unlikely to be resolved in a timely
> fashion, is making the perfect the enemy of the good.  

On Monday, February 3, 2020 2:52 PM Ian Levy wrote:
> Experiments will give us data that helps us make better solutions in the 
> future. If those solutions look like the current draft then great. If they
> don’t then we’ll be changing them based on data and experience. 

Lastly, I agree with Ian, Andrew, and others that making everything perfect 
now is the enemy of the good and we should move ahead with the experiment to 
get better data to make better solutions. I think that PSD DMARC will be 
valuable and should proceed.

Thanks,
-Eric

________________________
Eric Chudow
DoD Cybersecurity Mitigations

---

From: Hector Santos <[email-masked]>
Date: Wed, 05 Feb 2020 23:55:29 -0500

From a software engineering standpoint, we have an "Lookup" black box 
mechanism.  It should be left open-ended so the DMARC-bis can move it. 
  The default mechanism is the existing DMARC one. Consider PSD a 
Lookup extension to DMARCbis.    DMARCbis can describe "Lookup 
Extensions." Remember, we still TPA design issues and we have an 
extended lookup ATPS deployed.  Until we get a valid TPA method more 
systems accept, we will never be done with DKIM Policy modeling.

Can we please move on to completing DMARC as a standard?

On 2/3/2020 10:08 PM, Murray S. Kucherawy wrote:
> On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Murray,
>
>     <<<The chairs will not accept hearsay replies or opinions, or
>     expressions of needing this work but not knowing how to engage;
>     you either give your feedback on the list or privately to the
>     chairs or Area Directors, or you are along for whatever ride
>     results.  Please indicate, as soon as possible, where your support
>     lies given the above.>>>
>
>     In my capacity as managing director of fTLD Registry Services
>     (fTLD), registry operator of the .BANK and .INSURANCE TLDs, I
>     believe PSD would provide invaluable threat intelligence to domain
>     registrants and to TLD administrators like ourselves for
>     NXDOMAINs. PSD has tremendous value to specialized TLDs including,
>     but not limited to, .BRANDS, community-based domains,
>     high-security domains, governments, etc. and as such I believe PSD
>     should proceed. I’ve previously posted to this list expressing
>     this view and while fTLD cannot participate in experimentation due
>     to a prohibition by ICANN, we remain committed to supporting and
>     seeing this work continue.
>
>
> Craig,
>
> To be clear, however: I think the working group mailing list archive
> has enough of a record that participants think the experiment will be
> useful or even critical to the evolution of DMARC, though people are
> of course welcome to affirm that support for the record.  The question
> being put, however, goes to the form of the experiment and the current
> form of DMARC as a protocol with respect to determining Organizational
> Domains, and whether there are indeed risks to the deployed
> infrastructure that the experiment could become permanent.  That's the
> meaty stuff that would really help to move this along.
>
> -MSK
>
>

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 6 Feb 2020 19:44:32 +0100

>> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in

+1, albeit I don't think DMARCbis arrives so quickly

> like an ideal time to review and update our milestones.

There are quite some issues about DMARC.  Let me mention aggregate report
format first, as this brings out a third thing which can be done in parallel,
namely to publish http://dmarc.org/dmarc-xml/0.2.

Various tweaks have been proposed, I think they're well summarized in
http://bit.ly/dmarc-rpt-schema

For a second issue, consider whether report generators should track policy
changes during the day and, in case, send multiple reports with different
PolicyPublished.  Otherwise, PolicyPublished would be valid for only a part of
the reported rows, presumably the last.  Is that acceptable?

Another case for sending multiple reports at once is on hitting size limits.
Is better to increase sending frequency instead?  How to negotiate sending
frequency between report consumer's ri= and producer's conditions deserves some
discussion.

I'm sure there's a bunch of other issues, and we should start to collect them.

>> I don't see anything about PSD DMARC being inherently on the critical
>> path for DMARCbis.  I suspect the current major obstacle to DMARCbis is
>> that the question of how to take the PSL out of the equation is unsolved,
>> despite one IETF WG that was supposed to be dedicated to the question.>>
>> I don't think not publishing PSD DMARC helps move DMARCbis forward, so I 
>> think it's a false choice.>>
> 

+1, let DMARC core define _organizational domain_ by characteristics.  A second
document present a process, possibly demonstrating how the required
characteristics are met.

Scott's I-D already outlines the characteristics of Branded and
Multi-organization PSDs, that the experimental processes are suited for.

Best
Ale
--

---

From: Jane Moneypenny <[email-masked]>
Date: Thu, 13 Feb 2020 10:25:47 +0000

> the reported rows, presumably the last. Is that acceptable?

Shall the "policy tracking" mechanism take into consideration:-
- TTL,
- DNS cache issues?

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 6, 2020 7:44 PM, Alessandro Vesely <[email-masked]> wrote:

> > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman [email-masked] wrote:
> >
> +1, let DMARC core defineorganizational domain by characteristics. A second
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> dmarc mailing list
> [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Feb 2020 20:57:35 -0800

> +1, albeit I don't think DMARCbis arrives so quickly

I don't actually think there's much stopping us from beginning the work on
DMARCbis now.  Seth has dutifully been collecting those and putting them in
the group's tracker for a while now, and everyone else is invited to make
sure their favorite issues are thus recorded so we can go through them all
when the time comes.

With only a few weeks left in this chair, I won't pull that trigger now,
but you should all expect to get going on that before long.

> [...]

Please make sure that these are all recorded in the tracker so they can be
discussed and factored in when the time comes.

I'm sure there's a bunch of other issues, and we should start to collect
> them.

This started some time ago.  :-)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Feb 2020 21:30:59 -0800

On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz <[email-masked]> wrote:

> First, while I know you've said the needs of external actors won't weigh
> on your decision about moving forward, I would like to mention that
> having a stable reference for PSD DMARC will help us with working towards
> policy changes that would allow us to participate in this experiment.  It
> may not be important to the WG Chairs' decision on the draft, but there
> are stakeholders for whom it is important.
>

Just to be clear, I don't mean to suggest the restriction you're referring
to is invalid.  I'm sympathetic to the idea that some potential
participants in PSD are constrained by policies outside of their control or
ours.  But I look at it this way: A series of "X can't happen until Y
happens" assertions have been made over the last while, and the series is
roughly circular.  I don't mean to be insensitive to the pain of you or
others under external constraints, yet at the same time, from the
perspective of the IETF, those constraints are very much external and thus
are easier to disqualify as we try (sometimes desperately) to find a way
out of this deadlock we're in.

I will also be somewhat ashamed to hand Alexey a deadlocked working group
in March.  :-)

With my chair hat on, I'm leaning toward making the following consensus
evaluation: With a completed (and now seven month old) Working Group Last
Call on the PSD document, and as far as I can see no sustained objection,
we should proceed toward publication.  Unless someone wants to argue that
this is not the WG's consensus, we'll proceed at the end of next week.

To be specific:

Dave raised a post-WGLC concern that DMARC and its use of the PSL really
ought to be teased apart.  I have heard no objection to that, and in fact
have seen some support for it, so I consider that also to have consensus.
The part that does not appear to have consensus is that it is mandatory for
this to be done before the PSD work can proceed.

Dave also suggested that Experimental status is not procedurally
appropriate for this work, and stated some reasons.  There appear to be no
others lending support for this assertion either.  However, while I
disagree, and I believe I gave an existence proof to the contrary, I will
put this question to the working group: Can we solve this problem by
switching the document to Informational status, and can the working group
accept that outcome?  That seems an easy compromise, and I saw it proposed
but not fully discussed yet.  This seems quite reasonable as well when one
considers that PSD's proponents could very likely get the thing published
as an RFC via the Independent Stream if they continue to find no progress
here.  So, please discuss this option on the list and I'll measure
consensus on it at the end of next week as well when next steps are chosen.

Mike objected to PSD generally, also long after WGLC completed.  This too
does not appear to have swayed consensus.  (And he's been cogitating on
that thread for a few weeks now...)

As a reminder, we still need to do AD evaluation, an IETF-wide last call,
directorate reviews, and IESG evaluation before it lands in the RFC
editor's queue.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Feb 2020 12:58:49 +0100

On Thu 27/Feb/2020 05:57:35 +0100 Murray S. Kucherawy wrote:
>> format first, as this brings out a third thing which can be done in
>> parallel, namely to publish http://dmarc.org/dmarc-xml/0.2.
>> [...]
>>
> 

I've added tickets 31, 32, and 33.

The first two ones are Freddie's entries I found walking top down
http://bit.ly/dmarc-rpt-schema .  Then I stopped adding his entries, as I don't
fully understand some details.  Freddie, please get there[*] and edit as needed.

#33 is the proposal to substitute the <version> element with the URI of the
spec, so as to let automatic parsers understand the syntax.

When the WG agrees on XML format details, we can publish the resulting schema
at http://dmarc.org/dmarc-xml/0.2.

Best
Ale
-- 

[*] https://trac.ietf.org/trac/dmarc/

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Feb 2020 13:16:32 +0100

On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
> 
> With a completed (and now seven month old) Working Group Last Call on the
> PSD document, and as far as I can see no sustained objection, we should 
> proceed toward publication.

Great!

> I will put this question to the working group: Can we solve this problem by
> accept that outcome?

IMHO, experimental is appropriate.  There are three competing methods; maybe it
will be worth to maintain all of them indefinitely, maybe some of them will
turn out to be impractical or not used.  That's the experimental question.  The
sooner we run it the sooner the response.

If publishing as experimental would further delay publication, I'd accept
informational.  However, I don't understand why.

jm2c
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 27 Feb 2020 13:48:59 -0800

> > proceed toward publication.

+1

> informational.

Also agree.

--Kurt

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 27 Feb 2020 17:13:41 -0500

Informational works for me if that helps moves things forward.

I also agree with Mr. Crocker's thesis on teasing about the PSL from DMARC,
but that should not hinder forward progress on PSD.

tim

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 29 Feb 2020 18:47:02 -0500

> directorate reviews, and IESG evaluation before it lands in the RFC

As editor, I'm happy to update the draft to match whatever the chairs find as 
consensus.

Personally, I think informational is fine.  I'll wait for direction from the 
chairs before doing anything.

Scott K

Scott K