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

[Craig Schwartz <[e-mail]>]

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: [phone]
Mobile: [phone]
Skype: craig-schwartz
www.fTLD.com








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

> Dave,
>
> On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[e-mail]> 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
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>