Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

Thanks Barry

I sent a pull request along to Scott with the changes.

I also generated an rfcdiff which I include for completeness sake.

thanks
tim


On Sun, Feb 28, 2021 at 5:02 PM Barry Leiba  wrote:

> It looks right to me.  Thanks, Tim.
>
> Barry
>
> On Sun, Feb 28, 2021 at 4:53 PM Tim Wicinski  wrote:
>
>> I was just working on merging Barry's comments with Dave's and Kurt's.
>>
>> I attached what should be correct.  I would like someone to just double
>> check my work.
>>
>> tim
>>
>>
>> On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy 
>> wrote:
>>
>>> These all work for me.  Thanks for the contributions.
>>>
>>> Scott, please work your magic with a revision so the chairs can request
>>> publication and we can get this on its way.
>>>
>>> -MSK
>>>
>>> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:
>>>
 On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:

 Especially in the case of the PSD policies, one should not expect that
 the controlling organization would necessarily be "a mail-originating
 organization". Generally the idea is to *disavow* being such :-)

 Suggested alternate text:

 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
 permits a domain-controlling
 organization to express domain-level policies and preferences for
 message validation, disposition, and reporting,
 which a mail-receiving organization can use to improve mail handling.

 +1

 d/

 --
 Dave crockerdcroc...@gmail.com
 408.329.0791

 Volunteer, Silicon Valley Chapter
 American Red crossdave.crock...@redcross.org

 ___
 dmarc mailing list
 dmarc@ietf.org
 https://www.ietf.org/mailman/listinfo/dmarc

>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>
Title: Diff: draft-ietf-dmarc-psd-11.txt - draft-ietf-dmarc-psd-10.txt
 
 

 
 
 
 
 
 
 
   
   draft-ietf-dmarc-psd-11.txt   draft-ietf-dmarc-psd-10.txt  
   
  Network Working Group   S. Kitterman Network Working Group   S. Kitterman
  Internet-DraftfTLD Registry Services Internet-DraftfTLD Registry Services
  
  Intended status: ExperimentalJanuary 1, 2021 Intended status: Experimental   January 23, 2021
  Expires: July 5, 2021 Expires: July 27, 2021
   
   Experimental DMARC Extension For Public Suffix Domains  Experimental DMARC Extension For Public Suffix Domains
  
  draft-ietf-dmarc-psd-11 draft-ietf-dmarc-psd-10
   
  Abstract Abstract
   
  
 Domain-based Message Authentication, Reporting, and ConformanceDMARC (Domain-based Message Authentication, Reporting, and
 (DMARC) permits a domain-controlling organization to express domain-Conformance) is a scalable mechanism by which a mail-originating
 level policies and preferences for message validation, disposition,organization can express domain-level policies and preferences for
 and reporting, which a mail-receiving organization can use to improvemessage validation, disposition, and reporting, that a mail-receiving
 mail handling.organization can use to improve mail handling.  The design of DMARC
  presumes that domain names represent either nodes in the tree below
  which registrations occur, or nodes where registrations have
  occurred; it does not permit a domain name to have both of these
  properties simultaneously.  Since its deployment in 2015, use of
  DMARC has shown a clear need for the ability to express policy for
  these domains as well.
   
  
 DMARC distinguishes the portion of a name that is a Public SuffixDomains at which registrations can occur are referred to as Public
 Domain (PSD), below which organizational domain names are created.Suffix Domains (PSDs).  This document describes an extension to DMARC
 The basic DMARC capability allows organizational domains to specifyto enable DMARC functionality for PSDs.
 policies that apply to their subdomains, but it does not give that 
 capability to PSDs.  This document describes an extension to DMARC to 
 fully enable DMARC functionality for PSDs. 
   
  
 Some implementations of DMARC consider a PSD to be ineligible forThis document also seeks to address implementations that consider a
 DMARC enforcement.  This specification addresses that case.domain on a public Suffix list to be ineligible for DMARC
  enforcement.
   
  Status of This Memo 

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Barry Leiba]

It looks right to me.  Thanks, Tim.

Barry

On Sun, Feb 28, 2021 at 4:53 PM Tim Wicinski  wrote:

> I was just working on merging Barry's comments with Dave's and Kurt's.
>
> I attached what should be correct.  I would like someone to just double
> check my work.
>
> tim
>
>
> On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy 
> wrote:
>
>> These all work for me.  Thanks for the contributions.
>>
>> Scott, please work your magic with a revision so the chairs can request
>> publication and we can get this on its way.
>>
>> -MSK
>>
>> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:
>>
>>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>>>
>>> Especially in the case of the PSD policies, one should not expect that
>>> the controlling organization would necessarily be "a mail-originating
>>> organization". Generally the idea is to *disavow* being such :-)
>>>
>>> Suggested alternate text:
>>>
>>> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
>>> permits a domain-controlling
>>> organization to express domain-level policies and preferences for
>>> message validation, disposition, and reporting,
>>> which a mail-receiving organization can use to improve mail handling.
>>>
>>> +1
>>>
>>> d/
>>>
>>> --
>>> Dave crockerdcroc...@gmail.com
>>> 408.329.0791
>>>
>>> Volunteer, Silicon Valley Chapter
>>> American Red crossdave.crock...@redcross.org
>>>
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

I was just working on merging Barry's comments with Dave's and Kurt's.

I attached what should be correct.  I would like someone to just double
check my work.

tim


On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy 
wrote:

> These all work for me.  Thanks for the contributions.
>
> Scott, please work your magic with a revision so the chairs can request
> publication and we can get this on its way.
>
> -MSK
>
> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:
>
>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>>
>> Especially in the case of the PSD policies, one should not expect that
>> the controlling organization would necessarily be "a mail-originating
>> organization". Generally the idea is to *disavow* being such :-)
>>
>> Suggested alternate text:
>>
>> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
>> permits a domain-controlling
>> organization to express domain-level policies and preferences for message
>> validation, disposition, and reporting,
>> which a mail-receiving organization can use to improve mail handling.
>>
>> +1
>>
>> d/
>>
>> --
>> Dave crockerdcroc...@gmail.com
>> 408.329.0791
>>
>> Volunteer, Silicon Valley Chapter
>> American Red crossdave.crock...@redcross.org
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
— Abstract —

OLD
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.

NEW
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) permits a domain-controlling organization to express
   domain-level policies and preferences for message validation,
   disposition, and reporting, which a mail-receiving organization
   can use to improve mail handling.

DMARC distinguishes the portion of a name that is a
Public Suffix Domain (PSD), below which
organizational domain names are created.  The basic DMARC
capability allows organizational domains to specify policies
that apply to their subdomains, but it does not give that
capability to PSDs. This document describes an extension to
DMARC to fully enable DMARC functionality for PSDs.

Some implementations of DMARC consider a PSD to be ineligible for
DMARC enforcement.  This specification addresses that case.


— Section 1 —

OLD
   DMARC as specified presumes that domain names present in a PSL are
   not organizational domains and thus not subject to DMARC processing;
   domains are either organizational domains, sub-domains of
   organizational domains, or listed on a PSL.  For domains listed in a
   PSL, i.e., TLDs and domains that exist between TLDs and organization
   level domains, policy can only be published for the exact domain.  No
   method is available for these domains to express policy or receive
   feedback reporting for sub-domains.  This missing method allows for
   the abuse of non-existent organizational-level domains and prevents
   identification of domain abuse in email.

NEW
  In the basic DMARC model, PSDs are not organizational domains
  and are thus not subject to DMARC processing.  In DMARC, domains
  fall into one of three categories: organizational domains,
  sub-domains of organizational domains, or PSDs.  A PSD can only
  publish DMARC policy for itself, and not for any sub-domains
  under it.  In some cases, this limitation allows for the abuse
  of non-existent organizational-level domains and hampers
  identification of domain abuse in email.

— Section 1.1 —

OLD
   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (".gov.example" and
   ".com.example").  A PSL whose maintainer is aware of this country's
   domain structurewould include entries for both of these in the PSL,
   indicating that they are PSDs below which registrations can occur.
 

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

These all work for me.  Thanks for the contributions.

Scott, please work your magic with a revision so the chairs can request
publication and we can get this on its way.

-MSK

On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:

> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>
> Especially in the case of the PSD policies, one should not expect that the
> controlling organization would necessarily be "a mail-originating
> organization". Generally the idea is to *disavow* being such :-)
>
> Suggested alternate text:
>
> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
> permits a domain-controlling
> organization to express domain-level policies and preferences for message
> validation, disposition, and reporting,
> which a mail-receiving organization can use to improve mail handling.
>
> +1
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red crossdave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
Especially in the case of the PSD policies, one should not expect that 
the controlling organization would necessarily be "a mail-originating 
organization". Generally the idea is to *disavow* being such :-)


Suggested alternate text:

Domain-based Message Authentication, Reporting, and Conformance 
(DMARC) permits a domain-controlling
organization to express domain-level policies and preferences for 
message validation, disposition, and reporting,

which a mail-receiving organization can use to improve mail handling.


+1

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Kurt Andersen (b)]

This is getting much better - thanks for all the wordsmithing. I have one
nuance to add...

On Thu, Feb 25, 2021 at 6:13 AM Dave Crocker  wrote:

>
> The suggested revisions to Barry's suggested revisions, below, primarily
> serve to reference the PSD construct without needing to reference the
> PSL.  And, of course, there are various other suggested wording tweaks...
>
> EVEN NEWER
> Domain-based Message Authentication, Reporting, and
> Conformance (DMARC) permits a mail-originating
> organization to express domain-level policies and preferences for
> message validation, disposition, and reporting, which a mail-receiving
> organization can use to improve mail handling.
>

Especially in the case of the PSD policies, one should not expect that the
controlling organization would necessarily be "a mail-originating
organization". Generally the idea is to *disavow* being such :-)

Suggested alternate text:

Domain-based Message Authentication, Reporting, and Conformance (DMARC)
permits a domain-controlling
organization to express domain-level policies and preferences for message
validation, disposition, and reporting,
which a mail-receiving organization can use to improve mail handling.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

If everyone liked using the PSL and making it integral to DMARC, then 
that would be fine.  But they don't; so it isn't.


The suggested revisions to Barry's suggested revisions, below, primarily 
serve to reference the PSD construct without needing to reference the 
PSL.  And, of course, there are various other suggested wording tweaks...



On 2/24/2021 9:10 PM, Barry Leiba wrote:

— Abstract —


NEW
DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.

DMARC uses a Public Suffix List (PSL) to determine what part of a
domain name is the Public Suffix Domain (PSD), below which
organizational domain names are created.  DMARC allows organizational
domains to specify policies that apply to their subdomains, but it
does not give that flexibility to PSDs.

This document describes an extension to DMARC to fully enable DMARC
functionality for PSDs.  This document also addresses implementations
that consider a domain on a public Suffix list to be ineligible for
DMARC enforcement.


The major intention is removal of reference to /how/ it does the hierarchy 
distinction.  In case it ever uses a different mechanism that people like 
better...

EVEN NEWER
   Domain-based Message Authentication, Reporting, and
   Conformance (DMARC) permits a mail-originating
   organization to express domain-level policies and preferences for
   message validation, disposition, and reporting, which a mail-receiving
   organization can use to improve mail handling.

   DMARC distinguishes the portion of a name that is a
  Public Suffix Domain (PSD), below which
   organizational domain names are created.  The basic DMARC capability allows 
organizational
   domains to specify policies that apply to their subdomains, but it
   does not give that capability to PSDs. This document describes an extension 
to DMARC to
  fully enable DMARC
   functionality for PSDs.

   Some implementations of DMARC consider a PSD to be ineligible for
   DMARC enforcement.  This specification addresses that case.





— Section 1 —

NEW
DMARC as specified presumes that domain names present in a Public
Suffix List (PSL) — Public Suffix Domains (PSDs) — are not
organizational domains and are thus not subject to DMARC processing.
In DMARC, domains fall into one of three categories: organizational
domains, sub-domains of organizational domains, or PSDs.  For PSDs,
policy can only be published for the exact domain: no mechanism is
available for PSDs to express policy or receive feedback reporting
for sub-domains.  The lack of such a mechanism allows for the abuse
of non-existent organizational-level domains and hampers
identification of domain abuse in email.


EVEN NEWER

NEW
   In the basic DMARC model, PSDs are not
   organizational domains and are thus not subject to DMARC processing.
   In DMARC, domains fall into one of three categories: organizational
   domains, sub-domains of organizational domains, or PSDs.  A PSD
   can only publish DMARC policy for itself, and not for any sub-domains under 
it.
  In some cases, this limitation allows for the abuse
   of non-existent organizational-level domains and hampers
   identification of domain abuse in email.





— Section 1.1 —

OLD
As an example, imagine a country code TLD (ccTLD) which has public
subdomains for government and commercial use (".gov.example" and
".com.example").  A PSL whose maintainer is aware of this country's
domain structurewould include entries for both of these in the PSL,
indicating that they are PSDs below which registrations can occur.
Suppose further that there exists a domain "tax.gov.example",
registered within ".gov.example", that is responsible for taxation in
this imagined country.

NEW
As an example, imagine a Top-Level Domain (TLD), ".example", that has
public subdomains for government and commercial use (".gov.example"
and ".com.example").  A PSL whose maintainer is aware of this TLD’s
domain structure would include entries for both of these in the PSL,
indicating that they are PSDs below which organizational domains can
be registered.  Suppose further that there exists a legitimate domain
called "tax.gov.example", registered within ".gov.example".



EVEN NEWER
   As an example, imagine a Top-Level Domain (TLD), ".example", that has
   public subdomains for government and commercial use (".gov.example"
   and ".com.example").  The maintainer of a list of such a PSD structure
   would include entries for both of these sub-domains, thereby
   indicating that they are PSDs, below which organizational domains can
   be registered.  Suppose further that there 

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Barry Leiba]

OK, here's my proposal; please let me know what you think:

— Abstract —

OLD
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.

NEW
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.

   DMARC uses a Public Suffix List (PSL) to determine what part of a
   domain name is the Public Suffix Domain (PSD), below which
   organizational domain names are created.  DMARC allows organizational
   domains to specify policies that apply to their subdomains, but it
   does not give that flexibility to PSDs.

   This document describes an extension to DMARC to fully enable DMARC
   functionality for PSDs.  This document also addresses implementations
   that consider a domain on a public Suffix list to be ineligible for
   DMARC enforcement.


— Section 1 —

OLD
   DMARC as specified presumes that domain names present in a PSL are
   not organizational domains and thus not subject to DMARC processing;
   domains are either organizational domains, sub-domains of
   organizational domains, or listed on a PSL.  For domains listed in a
   PSL, i.e., TLDs and domains that exist between TLDs and organization
   level domains, policy can only be published for the exact domain.  No
   method is available for these domains to express policy or receive
   feedback reporting for sub-domains.  This missing method allows for
   the abuse of non-existent organizational-level domains and prevents
   identification of domain abuse in email.

NEW
   DMARC as specified presumes that domain names present in a Public
   Suffix List (PSL) — Public Suffix Domains (PSDs) — are not
   organizational domains and are thus not subject to DMARC processing.
   In DMARC, domains fall into one of three categories: organizational
   domains, sub-domains of organizational domains, or PSDs.  For PSDs,
   policy can only be published for the exact domain: no mechanism is
   available for PSDs to express policy or receive feedback reporting
   for sub-domains.  The lack of such a mechanism allows for the abuse
   of non-existent organizational-level domains and hampers
   identification of domain abuse in email.

— Section 1.1 —

OLD
   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (".gov.example" and
   ".com.example").  A PSL whose maintainer is aware of this country's
   domain structurewould include entries for both of these in the PSL,
   indicating that they are PSDs below which registrations can occur.
   Suppose further that there exists a domain "tax.gov.example",
   registered within ".gov.example", that is responsible for taxation in
   this imagined country.

NEW
   As an example, imagine a Top-Level Domain (TLD), ".example", that has
   public subdomains for government and commercial use (".gov.example"
   and ".com.example").  A PSL whose maintainer is aware of this TLD’s
   domain structure would include entries for both of these in the PSL,
   indicating that they are PSDs below which organizational domains can
   be registered.  Suppose further that there exists a legitimate domain
   called "tax.gov.example", registered within ".gov.example".



OLD
   This DMARC record provides policy and a reporting destination for
   mail sent from @gov.example.  However, due to DMARC's current method
   of discovering and applying policy at the organizational domain
   level, the non-existent organizational domain of @t4x.gov.example
   does not and cannot fall under a DMARC policy.

NEW
   This DMARC record provides policy and a reporting destination for
   mail sent from @gov.example.  Similarly, "tax.gov.example" will have
   a DMARC record that specifies policy for mail sent from addresses
   @tax.gov.example.  However, due to 

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Alessandro Vesely]

On Mon 22/Feb/2021 15:36:00 +0100 Ken O'Driscoll wrote:
I would go even further and not even talk about the trees and nodes. Also, 
echoing elsewhere in this thread, making it really clear that this is not a 
case of /DMARC is coming for your TLD/. So, I’d propose something super basic 
like this for the second paragraph:


Domain name suffixes (for example .com, .eu, and .co.uk) are controlled by 
registries, who either directly or through accredited registrars, facilitate 
the registration and management of domain names below these suffixes. DMARC 
currently permits expression of policy only for domain names and not for domain 
suffixes. Since its deployment in 2015, specialist use cases have been 
identified where it may be desirable for a suffix to express a DMARC policy. 
This document describes an experimental extension to DMARC to add that capability.



Clear and concise.  Just s/only for domain names/only for registered domain 
names/.


Best
Ale
--















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Ken O'Driscoll]

On Monday 22 February 2021 16:14, Dave Crocker wrote:
> Strictly speaking co.uk is not ICAN-authorized.  It's authorized by
> mechanisms internal to the UK.
> 

None of the ccTLDs registry operators would call or consider themselves 
"ICANN-authorized". The original authorisation to use the namespace is very 
separate to ICANN having any general authority over them. Further, it’s likely 
to be confused with the more common term "ICANN-accredited", which refers to a 
sub-set of domain registrars, not registries.

I think a better and more inclusive term would be "Internet Domain Registry".

Ken.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Douglas Foster]

That does not answer the question.  We can only clarify the registration
question by clarifying what entity's registration mechanism is in scope.

Do we simply say that this document applies to registrations occurring
immediately below an entry on the PSL?

On Mon, Feb 22, 2021, 11:14 AM Dave Crocker  wrote:

> On 2/22/2021 7:49 AM, Douglas Foster wrote:
> > So what is the best nomenclature for referring to the
> > "ICANN-authorized registries"?   Dave's phrase or something else?
>
> Strictly speaking co.uk is not ICAN-authorized.  It's authorized by
> mechanisms internal to the UK.
>
> d/
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[ned+dmarc]

>>> Actually that's a community that I would expect to know exactly what all 
those terms mean and
>>> how they are all related.



yes. But it's worse than that.  The current language is not
automatically clear even for folk with good knowledge about DNS
administration.



As is being noted, I too think a great deal of the problem is
over-reliance on the word register.



It is being used as if it explains a basic difference in administrative
roles.  It doesn't.  Not even close.




>> To work with the example you gave here, I agree that "facebook.com" is registered 
(under "com"), but
>> disagree that "www.facebook.com" is registered at all;



> Right, of course it's not.



I disagree.  Strongly.  The fact that one registration is internal and
another is through a third-party, semi-regulated service does not make a
difference, for the use of that word.



I work with an organization that has an IT department that is just as
formal typical ICANN-authorized registries.  To get a sub-domain is a
Very Big Deal.  Don't think for a moment that it is fundamentally
different than interacting with the TLD registeries.


Wow, I didn't know you had started working for Oracle! Welcome aboard! ;-)

Seriously, this is the rule, not the exception, with large organizations,
especially those that assign significant value to their domain reputations.
There are all kinds of hoops you have to jump through before you'll be able to
get a sub-domain, or for that matter a different name with the company name
embedded in it. And after it's registered, there are ongoing maintenance
requirements.

Registering a domain with, say, GoDaddy is a triviality by comparison.

The SSL certificate situation adds even more complexity, but fortunately
that's not relevant here.


> I didn't say that it is: I said that
> people who don't fully understand this stuff *think* it is, and that's
> the part that the text isn't making clear.



>> To my mind, "register" involves a specific transaction, sometimes involving 
money, with whoever gates
>> access to make those delegations.



How much do you pay to register to vote?



However the rest of the above statement is correct.  A transaction to
record gain access to a resource or to reserve access to it.



Registration is a process of signing up.  That's all.  And it says
nothing about the role or relationship of the entity the registration is
with.


Yep.

Ned

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 2/22/2021 7:49 AM, Douglas Foster wrote:
So what is the best nomenclature for referring to the 
"ICANN-authorized registries"?   Dave's phrase or something else?


Strictly speaking co.uk is not ICAN-authorized.  It's authorized by 
mechanisms internal to the UK.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Douglas Foster]

So what is the best nomenclature for referring to the "ICANN-authorized
registries"?   Dave's phrase or something else?

On Mon, Feb 22, 2021, 10:26 AM Dave Crocker  wrote:

>
> >>> Actually that's a community that I would expect to know exactly what
> all those terms mean and
> >>> how they are all related.
>
> yes. But it's worse than that.  The current language is not
> automatically clear even for folk with good knowledge about DNS
> administration.
>
> As is being noted, I too think a great deal of the problem is
> over-reliance on the word register.
>
> It is being used as if it explains a basic difference in administrative
> roles.  It doesn't.  Not even close.
>
>
> >> To work with the example you gave here, I agree that "facebook.com" is
> registered (under "com"), but
> >> disagree that "www.facebook.com" is registered at all;
> > Right, of course it's not.
>
> I disagree.  Strongly.  The fact that one registration is internal and
> another is through a third-party, semi-regulated service does not make a
> difference, for the use of that word.
>
> I work with an organization that has an IT department that is just as
> formal typical ICANN-authorized registries.  To get a sub-domain is a
> Very Big Deal.  Don't think for a moment that it is fundamentally
> different than interacting with the TLD registeries.
>
>
> > I didn't say that it is: I said that
> > people who don't fully understand this stuff *think* it is, and that's
> > the part that the text isn't making clear.
> >
> >> To my mind, "register" involves a specific transaction, sometimes
> involving money, with whoever gates
> >> access to make those delegations.
>
> How much do you pay to register to vote?
>
> However the rest of the above statement is correct.  A transaction to
> record gain access to a resource or to reserve access to it.
>
> Registration is a process of signing up.  That's all.  And it says
> nothing about the role or relationship of the entity the registration is
> with.
>
>
>
> d/
>
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

Actually that's a community that I would expect to know exactly what all those 
terms mean and
how they are all related.


yes. But it's worse than that.  The current language is not 
automatically clear even for folk with good knowledge about DNS 
administration.


As is being noted, I too think a great deal of the problem is 
over-reliance on the word register.


It is being used as if it explains a basic difference in administrative 
roles.  It doesn't.  Not even close.




To work with the example you gave here, I agree that "facebook.com" is registered (under 
"com"), but
disagree that "www.facebook.com" is registered at all;

Right, of course it's not.


I disagree.  Strongly.  The fact that one registration is internal and 
another is through a third-party, semi-regulated service does not make a 
difference, for the use of that word.


I work with an organization that has an IT department that is just as 
formal typical ICANN-authorized registries.  To get a sub-domain is a 
Very Big Deal.  Don't think for a moment that it is fundamentally 
different than interacting with the TLD registeries.




I didn't say that it is: I said that
people who don't fully understand this stuff *think* it is, and that's
the part that the text isn't making clear.


To my mind, "register" involves a specific transaction, sometimes involving 
money, with whoever gates
access to make those delegations.


How much do you pay to register to vote?

However the rest of the above statement is correct.  A transaction to 
record gain access to a resource or to reserve access to it.


Registration is a process of signing up.  That's all.  And it says 
nothing about the role or relationship of the entity the registration is 
with.




d/


--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Ken O'Driscoll]

I would go even further and not even talk about the trees and nodes. Also, 
echoing elsewhere in this thread, making it really clear that this is not a 
case of DMARC is coming for your TLD. So, I’d propose something super basic 
like this for the second paragraph:

Domain name suffixes (for example .com, .eu, and .co.uk) are controlled by 
registries, who either directly or through accredited registrars, facilitate 
the registration and management of domain names below these suffixes. DMARC 
currently permits expression of policy only for domain names and not for domain 
suffixes. Since its deployment in 2015, specialist use cases have been 
identified where it may be desirable for a suffix to express a DMARC policy. 
This document describes an experimental extension to DMARC to add that 
capability.

Ken.

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Monday 22 February 2021 07:09
To: Barry Leiba 
Cc: Dave Crocker ; IETF DMARC WG 
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
I agree that the abstract is unclear.  This makes no sense to me:

   domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.

I don't understand the distinction that it's trying to make between
the two possibilities.
I also don't see the antecedent to "these domains" in the final
sentence of that paragraph.

Beyond that:
> I'm at a loss to understand what's confusing.  I'm not convinced that 
> "registrations" in the
> context of domain names is unclear to a reader familiar with this space.

I am absolutely convinced that it is.  Think of people in M3AAWG, for
whom this is very relevant.  Many of them don't know much about
registries, registrars, and such, and in general, the average reader
won't understand the difference, from a "registration" standpoint,
between facebook.com<http://facebook.com> (which is registered) and 
"www.facebook.com<http://www.facebook.com>"
(which is not).  To the average reader, "facebook.com<http://facebook.com>" is 
registered
under com, and "www.facebook.com<http://www.facebook.com>" is registered under 
facebook.  And
the ones who don't think that will likely not understand why we can't
just talk about second-level domains and be done with it.

Actually that's a community that I would expect to know exactly what all those 
terms mean and how they are all related.

I think the use of "registered" seems to be the source of some of this 
confusion.  To work with the example you gave here, I agree that 
"facebook.com<http://facebook.com>" is registered (under "com"), but disagree 
that "www.facebook.com<http://www.facebook.com>" is registered at all; 
"facebook.com<http://facebook.com>" was delegated to some company that now 
"owns" that piece of the namespace tree and can create whatever it wants under 
there without any external arrangement.  To my mind, "register" involves a 
specific transaction, sometimes involving money, with whoever gates access to 
make those delegations.

All that needs to be explained in the Introduction, not the Abstract.
But the Abstract has to explain enough for a reader to understand why
she might or might not be interested in getting the document and
reading it.  So it's going to be tough to word it carefully and to
keep it concise.  But we have to.

Stressing a point:
We very clearly do NOT want to explain this stuff in the Abstract.  In
fact, we don't have to explain much at all in the Abstract.  What we
have to do is make sure that the Abstract doesn't say stuff that's
*wrong* or confusing.  So let's try to find some fifth-grade language
that can suffice, and then make sure the Introduction has the right
words to make it clear to people who know how to do email, but who
don't already understand the issues involved here.

How's this?:


   DMARC (Domain-based Message Authentication, Reporting, and

   Conformance) is a scalable mechanism by which a mail-originating

   organization can express domain-level policies and preferences for

   message validation, disposition, and reporting, that a mail-receiving

   organization can use to improve mail handling.

   Within the Domain Name System (DNS) on the public Internet, which is

   organized as a tree, some nodes of that tree are reserved for use by

   registrars, who delegate sub-trees to other operators on request.  DMARC 
currently
   permits expression of policy only for such sub-trees.  There is a marked 
desire to

   be able to express policy for the reserved nodes as well.  This document

   describes an experimental extension to DMARC to add that c

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Barry Leiba]

>> > I'm at a loss to understand what's confusing.  I'm not convinced that 
>> > "registrations" in the
>> > context of domain names is unclear to a reader familiar with this space.
>>
>> I am absolutely convinced that it is.  Think of people in M3AAWG, for
>> whom this is very relevant.  Many of them don't know much about
>> registries, registrars, and such, and in general, the average reader
>> won't understand the difference, from a "registration" standpoint,
>> between facebook.com (which is registered) and "www.facebook.com"
>> (which is not).  To the average reader, "facebook.com" is registered
>> under com, and "www.facebook.com" is registered under facebook.  And
>> the ones who don't think that will likely not understand why we can't
>> just talk about second-level domains and be done with it.
>
> Actually that's a community that I would expect to know exactly what all 
> those terms mean and
> how they are all related.

There clearly are some in that community who do.  But there are many
there who don't.  This stuff is more esoteric than those of us who are
in the middle of it often realize.

> I think the use of "registered" seems to be the source of some of this 
> confusion.

Yes, exactly.

> To work with the example you gave here, I agree that "facebook.com" is 
> registered (under "com"), but
> disagree that "www.facebook.com" is registered at all;

Right, of course it's not.  I didn't say that it is: I said that
people who don't fully understand this stuff *think* it is, and that's
the part that the text isn't making clear.

> To my mind, "register" involves a specific transaction, sometimes involving 
> money, with whoever gates
> access to make those delegations.

And that's what we need to explain better in the Introduction.

> How's this?:
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.
>
>Within the Domain Name System (DNS) on the public Internet, which is
>organized as a tree, some nodes of that tree are reserved for use by
>registrars, who delegate sub-trees to other operators on request.  DMARC 
> currently
>permits expression of policy only for such sub-trees.  There is a marked 
> desire to
>be able to express policy for the reserved nodes as well.  This document
>describes an experimental extension to DMARC to add that capability.
>
> If we like that as a replacement Abstract, I'll carry on and propose a 
> revision to the Introduction.

I don't think that really explains it properly either -- I think with
the above text, it's less confusing, but also not correct, or at least
not really indicative of what the document is proposing.

I don't have time today, but give me a couple of days to work on the
Abstract and the Introduction/Example, and I'll propose some specific
text that we can try out.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba  wrote:

> I agree that the abstract is unclear.  This makes no sense to me:
>
>domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>occurred; it does not permit a domain name to have both of these
>properties simultaneously.
>
> I don't understand the distinction that it's trying to make between
> the two possibilities.
> I also don't see the antecedent to "these domains" in the final
> sentence of that paragraph.
>
> Beyond that:
> > I'm at a loss to understand what's confusing.  I'm not convinced that
> "registrations" in the
> > context of domain names is unclear to a reader familiar with this space.
>
> I am absolutely convinced that it is.  Think of people in M3AAWG, for
> whom this is very relevant.  Many of them don't know much about
> registries, registrars, and such, and in general, the average reader
> won't understand the difference, from a "registration" standpoint,
> between facebook.com (which is registered) and "www.facebook.com"
> (which is not).  To the average reader, "facebook.com" is registered
> under com, and "www.facebook.com" is registered under facebook.  And
> the ones who don't think that will likely not understand why we can't
> just talk about second-level domains and be done with it.
>

Actually that's a community that I would expect to know exactly what all
those terms mean and how they are all related.

I think the use of "registered" seems to be the source of some of this
confusion.  To work with the example you gave here, I agree that "
facebook.com" is registered (under "com"), but disagree that "
www.facebook.com" is registered at all; "facebook.com" was delegated to
some company that now "owns" that piece of the namespace tree and can
create whatever it wants under there without any external arrangement.  To
my mind, "register" involves a specific transaction, sometimes involving
money, with whoever gates access to make those delegations.

All that needs to be explained in the Introduction, not the Abstract.
> But the Abstract has to explain enough for a reader to understand why
> she might or might not be interested in getting the document and
> reading it.  So it's going to be tough to word it carefully and to
> keep it concise.  But we have to.
>
> Stressing a point:
> We very clearly do NOT want to explain this stuff in the Abstract.  In
> fact, we don't have to explain much at all in the Abstract.  What we
> have to do is make sure that the Abstract doesn't say stuff that's
> *wrong* or confusing.  So let's try to find some fifth-grade language
> that can suffice, and then make sure the Introduction has the right
> words to make it clear to people who know how to do email, but who
> don't already understand the issues involved here.
>

How's this?:

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.

   Within the Domain Name System (DNS) on the public Internet, which is

   organized as a tree, some nodes of that tree are reserved for use by

   registrars, who delegate sub-trees to other operators on request.
DMARC currently
   permits expression of policy only for such sub-trees.  There is a
marked desire to

   be able to express policy for the reserved nodes as well.  This document

   describes an experimental extension to DMARC to add that capability.

If we like that as a replacement Abstract, I'll carry on and propose a
revision to the Introduction.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Steven M Jones]

On 2/21/21 08:49, Chudow, Eric B CIV NSA DSAW (USA) wrote:
> I think it's getting better, but I wouldn't call them Internet Naming 
> Authorities. Should we just call them higher-level entities?

There are proper names for these actors - there's no need to be even
more vague ...


> Also, while the biggest help that PSD DMARC would make is for non-existent 
> organizational domains, it can also help with other domains that haven't 
> expressed a DMARC policy, so the abstract shouldn't only discuss unregistered 
> domains.

Except for the few cases where the registrar for a given TLD mandates
DMARC participation and/or certain policies, there should be no language
that sounds like /imposing/ DMARC on domains where the domain
owner/operator has not elected to do so. Loose language here will not be
received well.


--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Chudow, Eric B CIV NSA DSAW (USA)]

I think it's getting better, but I wouldn't call them Internet Naming 
Authorities. Should we just call them higher-level entities? Also, while the 
biggest help that PSD DMARC would make is for non-existent organizational 
domains, it can also help with other domains that haven't expressed a DMARC 
policy, so the abstract shouldn't only discuss unregistered domains.

How about this:
--
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a 
scalable mechanism by which a mail-originating organization can express policy 
preferences for validation and disposition of messages which purport to come 
from owned domains, as well as requesting feedback reporting about those 
message validation and disposition actions. These features allow the Domain 
Owner to detect and inhibit domain name abuse.

DMARC is designed for use by individual Domain Owners or organizational Domain 
Owners for their domains and sub-domains. Consequently, DMARC preferences by 
higher-level entities that have Organizational Domains below them in the DNS 
hierarchy cannot be specified for sub-domains in their purview. Those 
higher-level entities have an interest in detecting and inhibiting domain name 
abuse for domain names within their section of the DNS tree, and message 
recipients have an interest in preventing deception by entities using those 
domain names as well. Since its deployment in 2015, use of DMARC has shown a 
clear need for the ability to express policy preferences for these domains.

Domains at which higher-level entities accept registrations by multiple 
organizations or other separate entities are referred to as Public Suffix 
Domains (PSDs).  This document describes an extension to DMARC to enable DMARC 
functionality for PSDs. It also addresses implementations that consider a 
domain on a Public Suffix List to be ineligible for DMARC enforcement.

This document also describes an extension to DMARC to specify separate, often 
stricter, policy preferences for non-existent sub-domains.
--

Thanks,
-Eric

___
Eric Chudow
DoD Cybersecurity Mitigations
410-854-5735, eric.b.chudow@mail.mil

From: Douglas Foster  
Sent: Saturday, February 20, 2021 9:01 AM
To: Dave Crocker 
Cc: Murray S. Kucherawy ; IETF DMARC WG 
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

This wording attempts to address the objections by giving
"registration" a specific context.    I also rewrote some of it for readability.

- -

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can policies and preferences for validation and 
disposition of messages which purport to come from owned domains, 
as well as requesting feedback reporting about those message 
validation and disposition actions.  These features allow the domain 
owner to detect and inhibit domain name abuse.

DMARC is designed for use by domain owners.  Consequently it has no 
applicability for domains that have no owner because the domain has 
never been registered with an Internet Naming Authority.  Those 
authorities have an interest in detecting and inhibiting abuse of the 
name registration process, and message recipients have an interest
in preventing deception by entities using unregistered organization 
domain names.

Domains at which Internet Naming Authorities perform registration are 
referred to as Public  Suffix Domains (PSDs).  This document describes 
an extension to DMARC to enable DMARC functionality for PSDs.

 This document also seeks to address implementations that consider a
 domain on a public Suffix list to be ineligible for DMARC
 enforcement.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Douglas Foster]

This wording attempts to address the objections by giving
"registration" a specific context.I also rewrote some of it for
readability.

- -

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can policies and preferences for validation and
disposition of messages which purport to come from owned domains,
as well as requesting feedback reporting about those message
validation and disposition actions.  These features allow the domain
owner to detect and inhibit domain name abuse.

DMARC is designed for use by domain owners.  Consequently it has no
applicability for domains that have no owner because the domain has
never been registered with an Internet Naming Authority.  Those
authorities have an interest in detecting and inhibiting abuse of the
name registration process, and message recipients have an interest
in preventing deception by entities using unregistered organization
domain names.

Domains at which Internet Naming Authorities perform registration are
referred to as Public  Suffix Domains (PSDs).  This document describes
an extension to DMARC to enable DMARC functionality for PSDs.

 This document also seeks to address implementations that consider a
 domain on a public Suffix list to be ineligible for DMARC
 enforcement.

On Fri, Feb 19, 2021 at 11:12 PM Dave Crocker  wrote:

> On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote:
>
> Circling back to this:
>
> On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker  wrote:
>
>> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>>
>> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:
>>
>>>organization can use to improve mail handling.  The design of DMARC
>>>presumes that domain names represent either nodes in the tree below
>>>which registrations occur, or nodes where registrations have
>>>
>>> DMARC does not have 'registrations'.
>>>
>>
>> ...
>>
>>
>> I'm struggling to understand the concern here.  I think we all know what
> it means to register a domain, and that the namespace is arranged as a
> tree,
>
>
> With the intent of building upon Barry's note:
>
>  Specification writing requires clarity of who the reader is and
> empathy with the experience they will have reading the document.
> 
>
> In that context "we all know" is automatically a red flag for requiring
> overly insider expertise.
>
> However in this case, I think the problem is worse.
>
> Simply put, I believe the text does not say what it means to distinguish,
> even for an expert reader.  So, yes, we all know what you say we know.
>
> But in fact that's not the point of the text.  It's trying to make some
> other point,  I assume it's about a type of boundary status, but it doesn't
> say that, nevermind saying it clearly and with enough technical and
> semantic detail to distinguish it.
>
> The text you offer:
>
> Maybe this is better, just for the sake of having something else to look
> at?
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.  The design of DMARC
>presumes that domain names represent nodes in the DNS tree that are either
>reserved as points below which new domain name registrations are made, or 
> are
>the results of those registrations; it does not permit a node to have both 
> of these
>properties simultaneously.  Since its deployment in 2015, use of
>DMARC has shown a clear need for the ability to express policy for
>these domains as well.
>
> moves closer to the mark, I think, but still doesn't get there.
>
> EVERY node can have sub-nodes registered.  So it isn't clear what
> 'reserved' means.
>
> Worse is that:
>
>reserved as points below which new domain name registrations are made, or 
> are
>the results of those registrations; it does not permit a node to have both 
> of these
>properties simultaneously.
>
> doesn't make sense to me.  I suspect an average technical reader will be
> at least as confused as I am.
>
> d/
>
>
> --
>
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red crossdave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote:

Circling back to this:

On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker > wrote:


On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker mailto:dcroc...@gmail.com>> wrote:


organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have

DMARC does not have 'registrations'.


...


I'm struggling to understand the concern here.  I think we all know 
what it means to register a domain, and that the namespace is arranged 
as a tree,



With the intent of building upon Barry's note:

 Specification writing requires clarity of who the reader is 
and empathy with the experience they will have reading the document.  



In that context "we all know" is automatically a red flag for requiring 
overly insider expertise.


However in this case, I think the problem is worse.

Simply put, I believe the text does not say what it means to 
distinguish, even for an expert reader.  So, yes, we all know what you 
say we know.


But in fact that's not the point of the text.  It's trying to make some 
other point,  I assume it's about a type of boundary status, but it 
doesn't say that, nevermind saying it clearly and with enough technical 
and semantic detail to distinguish it.


The text you offer:

Maybe this is better, just for the sake of having something else to 
look at?


DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent nodes in the DNS tree that are either
reserved as points below which new domain name registrations are made, or 
are
the results of those registrations; it does not permit a node to have both 
of these
properties simultaneously.  Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.

moves closer to the mark, I think, but still doesn't get there.

EVERY node can have sub-nodes registered.  So it isn't clear what 
'reserved' means.


Worse is that:

   reserved as points below which new domain name registrations are made, or are
   the results of those registrations; it does not permit a node to have both 
of these
   properties simultaneously.

doesn't make sense to me.  I suspect an average technical reader will be 
at least as confused as I am.


d/


--

Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Barry Leiba]

I agree that the abstract is unclear.  This makes no sense to me:

   domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.

I don't understand the distinction that it's trying to make between
the two possibilities.
I also don't see the antecedent to "these domains" in the final
sentence of that paragraph.

Beyond that:
> I'm at a loss to understand what's confusing.  I'm not convinced that 
> "registrations" in the
> context of domain names is unclear to a reader familiar with this space.

I am absolutely convinced that it is.  Think of people in M3AAWG, for
whom this is very relevant.  Many of them don't know much about
registries, registrars, and such, and in general, the average reader
won't understand the difference, from a "registration" standpoint,
between facebook.com (which is registered) and "www.facebook.com"
(which is not).  To the average reader, "facebook.com" is registered
under com, and "www.facebook.com" is registered under facebook.  And
the ones who don't think that will likely not understand why we can't
just talk about second-level domains and be done with it.

All that needs to be explained in the Introduction, not the Abstract.
But the Abstract has to explain enough for a reader to understand why
she might or might not be interested in getting the document and
reading it.  So it's going to be tough to word it carefully and to
keep it concise.  But we have to.

Stressing a point:
We very clearly do NOT want to explain this stuff in the Abstract.  In
fact, we don't have to explain much at all in the Abstract.  What we
have to do is make sure that the Abstract doesn't say stuff that's
*wrong* or confusing.  So let's try to find some fifth-grade language
that can suffice, and then make sure the Introduction has the right
words to make it clear to people who know how to do email, but who
don't already understand the issues involved here.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

Circling back to this:

On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker  wrote:

> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>
> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:
>
>>
>> Abstract
>>
>>DMARC (Domain-based Message Authentication, Reporting, and
>>Conformance) is a scalable mechanism by which a mail-originating
>>organization can express domain-level policies and preferences for
>>message validation, disposition, and reporting, that a mail-receiving
>>organization can use to improve mail handling.  The design of DMARC
>>presumes that domain names represent either nodes in the tree below
>>which registrations occur, or nodes where registrations have
>>
>> DMARC does not have 'registrations'.
>>
>
> It's referring to domain name registrations, not DMARC registrations.
>
> Also the occur/occured contrast has no obvious meaning to me.  Really, I
>> have no idea what's intended by it.
>>
> "exist"?
> "take place"?
> "are made"?
> "are done"?
>
> The issue wasn't synonyms but semantics.  'registrations occurred' has no
> obvious DMARC meaning.
>
> unless, perhaps, the meaning is 'domain names exist', but that still
> doesn't explain the contrast being drawn.
>
I'm struggling to understand the concern here.  I think we all know what it
means to register a domain, and that the namespace is arranged as a tree,
and that trees are made up of nodes, and that some nodes are above the cut
where registrations take place while the rest are below.  What other
meaning might someone in this space infer from this text?

Maybe this is better, just for the sake of having something else to look at?

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent nodes in the DNS tree that are either
   reserved as points below which new domain name registrations are made, or are
   the results of those registrations; it does not permit a node to
have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

Apart from that, I'm at a loss to understand what's confusing.  I'm not
convinced that "registrations" in the context of domain names is unclear to
a reader familiar with this space.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker > wrote:




Abstract

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have

DMARC does not have 'registrations'.


It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me. 
Really, I have no idea what's intended by it.

"exist"?
"take place"?
"are made"?
"are done"?


The issue wasn't synonyms but semantics.  'registrations occurred' has 
no obvious DMARC meaning.


unless, perhaps, the meaning is 'domain names exist', but that still 
doesn't explain the contrast being drawn.






occurred; it does not permit a domain name to have both of these

"both" of what?  registration?


It's describing properties of nodes in the domain name tree. DMARC's 
current design stipulates that every node is either (a) a node below 
which registrations can occur, or (b) a node at which a registration 
has occurred.  An example of the former is "org", and an example of 
the latter is "ietf.org " and its entire subtree.


DMARC does not have 'registrations'.

The word in used in the spec as:

"


   3 . Terminology and
   Definitions

Domain Owner:  An entity or organization that owns a DNS domain.  The
  term "owns" here indicates that the entity or organization being
  referenced holds the registration of that DNS domain."


and:


"


 3.2 .
 Organizational Domain



   The Organizational Domain is determined using the following
   algorithm:

   1.  Acquire a "public suffix" list, i.e., a list of DNS domain names
   reserved for registrations. "

(The later reference to the Tag Registry is presumably irrelevant here.)





properties simultaneously.  Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.

Which domains?


The intent is to augment DMARC's ability to describe the domain name 
tree such that a node can be both (a) and (b) at the same time, for 
the purposes of policy expression.  So those are the nodes (domains) 
of interest.



My frustration is that a document that reaches wg Last Call should not 
have language that is this confusing, especially about its fundamentals 
and especially given how much revision it has already gotten.




d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:

>
> Abstract
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.  The design of DMARC
>presumes that domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>
> DMARC does not have 'registrations'.
>

It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me.  Really, I
> have no idea what's intended by it.
>
"exist"?
"take place"?
"are made"?
"are done"?

>
>occurred; it does not permit a domain name to have both of these
>
> "both" of what?  registration?
>

It's describing properties of nodes in the domain name tree.  DMARC's
current design stipulates that every node is either (a) a node below which
registrations can occur, or (b) a node at which a registration has
occurred.  An example of the former is "org", and an example of the latter
is "ietf.org" and its entire subtree.

   properties simultaneously.  Since its deployment in 2015, use of
>DMARC has shown a clear need for the ability to express policy for
>these domains as well.
>
> Which domains?
>

The intent is to augment DMARC's ability to describe the domain name tree
such that a node can be both (a) and (b) at the same time, for the purposes
of policy expression.  So those are the nodes (domains) of interest.


>Domains at which registrations can occur are referred to as Public
>Suffix Domains (PSDs).  This document describes an extension to DMARC
>to enable DMARC functionality for PSDs.
>
> This is the definition of public suffix provided by the PSL folk:
>
> "A public suffix is a set of DNS names or wildcards concatenated with
> dots. It represents the part of a domain name which is *not* under the
> control of the individual registrant."
>

That seems to say the same thing to me, though perhaps more crisply.

>
>This document also seeks to address implementations that consider a
>domain on a public Suffix list to be ineligible for DMARC
>enforcement.
>
> seeks?
> [...]
>

Hmm.  Maybe that sentence can be struck entirely.  Is this a problem with
certain implementations only, or with DMARC as specified in 7489?  If the
latter, I think we can drop this because the main paragraph already says
this.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 1/29/2021 6:59 AM, Tim Wicinski wrote:
This starts a *one week* Working Group Last Call. 



Sorry, but even the Abstract appears to be littered with problematic 
language.


I always try to provide alternate language, when I can, but in spite of 
having offered suggestions for this document in the past, I can't for 
this set.




Abstract

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have

DMARC does not have 'registrations'.

Also the occur/occured contrast has no obvious meaning to me. Really, I 
have no idea what's intended by it.




occurred; it does not permit a domain name to have both of these

"both" of what?  registration?



properties simultaneously.  Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.

Which domains?



Domains at which registrations can occur are referred to as Public
Suffix Domains (PSDs).  This document describes an extension to DMARC
to enable DMARC functionality for PSDs.

This is the definition of public suffix provided by the PSL folk:

"A public suffix is a set of DNS names or wildcards concatenated with 
dots. It represents the part of a domain name which is *not* under the 
control of the individual registrant."




This document also seeks to address implementations that consider a
domain on a public Suffix list to be ineligible for DMARC
enforcement.

seeks?

implementations don't 'consider' anything.

is 'ineligibility' really the essential issue?

d/


--

Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

All

We've done a number of updates to the PSD document to reflect the GEN-ART
review,
mostly to expand on the experiments.  There has been enough changes that we
want to do a short
working group last call.

https://tools.ietf.org/html/draft-ietf-dmarc-psd-10

To look at the differences, I would suggest looking at this diff from the
-08 version and the current version:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-10

This starts a *one week* Working Group Last Call.  Please review the
changes and offer up comments.
Offering suggestive text would be really useful as well.

This WGLC will end 5 February 2021

tim


-- Forwarded message -
From: 
Date: Sat, Jan 23, 2021 at 6:26 PM
Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-10.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain-based Message Authentication,
Reporting & Conformance WG of the IETF.

Title   : Experimental DMARC Extension For Public Suffix
Domains
Author  : Scott Kitterman
Filename: draft-ietf-dmarc-psd-10.txt
Pages   : 14
Date: 2021-01-23

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-10
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc