Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[John Levine]

It appears that Brotman, Alex  said:
>To summarize,
>
>We'd like to see extensions available both below the "feedback" and "record" 
>elements.  The -02 draft only has it below the "feedback" element.  I agree 
>that all
>elements, each time they are utilized, should mention a reference as to how 
>they are to be utilized.
>
>We'd also like to have extensions go through an IETF process, however, we also 
>understand that we cannot exclude third parties from defining/deploying their 
>own
>extensions.  I suppose we could tell report receivers they "MUST" ignore any 
>extensions which are not IETF-approved, though that seems a bit heavy-handed.

Remember, IETF standards are about how to interoperate.  If people want to 
interpret private extensions,
that is fine so long as the private ones don't interfere with public ones.

While we would like it if people published the details of their private 
extensions, just knowing the
names is useful since that keeps names from colliding.  So we should set up a 
FCFS registry for
extensions, specification would be nice but not required.

R's,
John

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Alessandro Vesely]

On Mon 14/Jun/2021 14:41:44 +0200 Brotman, Alex wrote:


I agree that all elements, each time they are utilized, should mention a 
reference as to how they are to be utilized.

[...]

So, a sample report may look something like:


  2.0
  
2



So why doesn't  mention a reference to how it is utilized?

About that overabundance of 's, the 1st entry, right below , is the aggregate report 
version.  Thus far, we agreed that it is useless as a grammar indication if  contains its namespace 
declaration.  However, Matt noted that there may be parsers that consider reports to be pre-IETF drafts if they 
miss the  element.  In this case, it makes sense to keep 1.0 for 
backward compatibility, especially if we try not to break existing parsers.

The second  entry, inside , had better wear a 
different name, to avoid confusion.  I assume it's meant to be the report reference 
version.  A couple of alternative examples:


  
https://github.com/trusteddomainproject/OpenDMARC/releases/tag/rel-opendmarc-1-4-1

or


  
http://www.trusteddomain.org/opendmarc/
1.4.1
  


Best
Ale
--
























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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Trent Adams]

+1


On 6/14/21, 6:42 AM, "dmarc on behalf of Brotman, Alex" 
 
wrote:

To summarize,

We'd like to see extensions available both below the "feedback" and 
"record" elements.  The -02 draft only has it below the "feedback" element.  I 
agree that all elements, each time they are utilized, should mention a 
reference as to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we 
also understand that we cannot exclude third parties from defining/deploying 
their own extensions.  I suppose we could tell report receivers they "MUST" 
ignore any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   
 2.0
 
   2
   Sample Reporter
   report_sen...@example-reporter.com
   ...
   3v98abbp8ya9n3va8yr8oa3ya
   
 161212415
 161221511
   
 
 
   example.com
   quarantine
   none
   100
 
 
   
 192.168.4.4
 123
 
   quarantine
   pass
   fail
 
   
   
 example.com
   
   
 
   example.com
   pass
   abc123
 
 
   example.com>
   fail
 
   

  
 .
  
   
 

   

   

   

The goal being to allow extensions to live either at the reported-IP level, 
or at the domain level.

Does this seem reasonable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
    > To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an  container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >  > 
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLOwusINU$
 ">
>  > [...]
> > > 
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLNemKNFV$
 ">
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined 
to define
> the extension name in a different way for consistent non-use of 
attributes. But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >>  element
> >
> >
> > Both, and both optional.  An extension can have some data to add in
> > some , but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt

___
dmarc mailing list
dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLIcIrQ-o$
 

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Brotman, Alex]

To summarize,

We'd like to see extensions available both below the "feedback" and "record" 
elements.  The -02 draft only has it below the "feedback" element.  I agree 
that all elements, each time they are utilized, should mention a reference as 
to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we also 
understand that we cannot exclude third parties from defining/deploying their 
own extensions.  I suppose we could tell report receivers they "MUST" ignore 
any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   
 2.0
 
   2
   Sample Reporter
   report_sen...@example-reporter.com
   ...
   3v98abbp8ya9n3va8yr8oa3ya
   
 161212415
 161221511
   
 
 
   example.com
   quarantine
   none
   100
 
 
   
 192.168.4.4
 123
 
   quarantine
   pass
   fail
 
   
   
 example.com
   
   
 
   example.com
   pass
   abc123
 
 
   example.com>
   fail
 
   

  
 .
  
   
 

   

   

   

The goal being to allow extensions to live either at the reported-IP level, or 
at the domain level.

Does this seem reasonable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an  container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >  > xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0;>
>  > [...]
> > > xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0;>
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined to 
> define
> the extension name in a different way for consistent non-use of attributes. 
> But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >>  element
> >
> >
> > Both, and both optional.  An extension can have some data to add in
> > some , but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Matthäus Wander]

Alessandro Vesely wrote on 2021-06-04 11:26:
Second, I'm not sure we need an  container.  
I'd go for an example like, say, so:


[...]
    xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0;>

> [...]
   xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0;>


If we use an attribute for the extension name, then we don't the 
container section.
As the current schema does not use attributes at all, I'm more inclined 
to define the extension name in a different way for consistent non-use 
of attributes. But that's a minor detail.


1) Extensions in their own section (as it is now) or within each  
element



Both, and both optional.  An extension can have some data to add in some 
, but not necessarily in all of them.


+1

Regards,
Matt



smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Matthäus Wander]

ARC shows the need for extension data within  elements:


Example from RFC 8617:

 none
 fail
 fail
 
  local_policy
  arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A
 


With proper extension support, this example could look like this:

  
none
fail
fail

  extension
  arc=pass

  

...

  
pass

  
2
d2.example
s2
  
  
1
d1.example
s3
2001:DB8::1A
  

  


An IANA registry could serve as repository of IETF-approved extensions.

It's worth considering whether certain elements should be defined as 
extensible. In the above example, the  element could be placed 
below  next to the existing  and  elements. 
Implementations support this behavior by simply ignoring unknown 
elements. XML Schema supports extensibility in well-defined places with 
the  element.


Regards,
Matt

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Dotzero]

On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex  wrote:

> Hello folks,
>
> During our interim call last week the topic of extensions within the DMARC
> aggregate report came up.  There was a discussion about how to best
> introduce these, but also how they might be best used.  I noted three cases
> that I could see today; ARC, PSD, and BIMI.   And indeed we have tickets
> relating to the first two.  The original thought was that the aggregate
> draft would allow a place for extensions, and then additional drafts would
> define those within the IETF.  When -02 was originally being worked on,
> there was a thread about how we might like to see this, though not many
> responses.  The result is in section 4 of the -02 draft [1]. and I thought
> we'd enhance that as we progressed.  At the time, I didn't intend to limit
> the extensions to IETF-approved extensions, though wasn't sure how else
> this might be used by reporting entities (I mentioned domain reputation-ish
> things during the call).  I'd consider that if we don't enforce
> IETF-registered extensions, the receivers could still
>   ignore extensions they don't want to handle.  I'm also aware this could
> bloat a report in terms of size, though we've already indicated we don't
> seem overly concerned with the size of the XML body.  A few things I'd like
> to see the group reach consensus on are:
>
> 1) Extensions in their own section (as it is now) or within each 
> element
> 2) Must extensions be IETF-approved
> 3) If (2) is true, do we want to define any during the DMARCbis process
> (essentially a demonstration of how it is to be done)
>
> Thank you for your continued feedback
>
> 1:
> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>



1) Extensions should be in their own extension and seperate from the core
reporting. There is a reason we call them "extensions".
2) Extensions used in reporting under the standard should be IETF-approved.
This is a standards body. Anyone can leverage standards for private use but
our focus as an IETF working group is interoperability. By requiring IETF
approval/registration it puts the extensions under IETF "Note Well" and
makes the extension public.

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Trent Adams]

I agree with Alessandro's suggestions, and really like the flexibility of 
self-labeled elements so they can be located where appropriate rather than 
forcing all extensions into a single bucket.

My $0.02,
Trent


On 6/4/21, 3:27 AM, "dmarc on behalf of Alessandro Vesely" 
 wrote:

On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote:
> 
> During our interim call last week the topic of extensions within the 
DMARC aggregate report came up.  There was a discussion about how to best 
introduce these, but also how they might be best used.  I noted three cases 
that I could see today; ARC, PSD, and BIMI.   And indeed we have tickets 
relating to the first two.  The original thought was that the aggregate draft 
would allow a place for extensions, and then additional drafts would define 
those within the IETF.  When -02 was originally being worked on, there was a 
thread about how we might like to see this, though not many responses.  The 
result is in section 4 of the -02 draft [1].


I have some comments about that attempt.  First, it shows extensions right 
below , while it seems more useful to have them as child of . 
 Second, I'm not sure we need an  container.  I'd go for an example 
like, say, so:

https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/dmarc-xml/1.0__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKqvwSJvF$
 ">

   ...


   ...

https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKvQ2pQn-$
 ">
   ...


   
  ...
   
   
  ...
   
   
  ...
   
  ...
   https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtkFNC6p$
 ">
  ...
   


   ...




Third, we need to grasp how XML grammars can be composed, and insert it in 
Appendix A.


>  At the time, I didn't intend to limit the extensions to IETF-approved 
extensions, though wasn't sure how else this might be used by reporting 
entities (I mentioned domain reputation-ish things during the call).  I'd 
consider that if we don't enforce IETF-registered extensions, the receivers 
could still ignore extensions they don't want to handle.


I assume no one reads the XML directly, except for debugging.  If report 
consumers don't know about an extension, its content will never reach human 
eyeballs.  Extension existence will have to be advertised, and a IANA page 
could be a decent means of doing that.


>  I'm also aware this could bloat a report in terms of size, though we've 
already indicated we don't seem overly concerned with the size of the XML body. 
 A few things I'd like to see the group reach consensus on are:
> 
> 1) Extensions in their own section (as it is now) or within each  
element


Both, and both optional.  An extension can have some data to add in some 
, but not necessarily in all of them.


> 2) Must extensions be IETF-approved


We cannot stop non-registered extensions.  Yet, developers may want to see 
an RFC before implementing code that extracts a given extension's content.


> 3) If (2) is true, do we want to define any during the DMARCbis process 
(essentially a demonstration of how it is to be done)


It would be a good way to show how to define them.  Not our primary task, 
though.


Best
Ale
-- 

> 1: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02*section-4__;Iw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtSg8JaH$
 



















___
dmarc mailing list
dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKn_Uzf5Y$
 

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Alessandro Vesely]

On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote:


During our interim call last week the topic of extensions within the DMARC 
aggregate report came up.  There was a discussion about how to best introduce 
these, but also how they might be best used.  I noted three cases that I could 
see today; ARC, PSD, and BIMI.   And indeed we have tickets relating to the 
first two.  The original thought was that the aggregate draft would allow a 
place for extensions, and then additional drafts would define those within the 
IETF.  When -02 was originally being worked on, there was a thread about how we 
might like to see this, though not many responses.  The result is in section 4 
of the -02 draft [1].



I have some comments about that attempt.  First, it shows extensions right below 
, while it seems more useful to have them as child of .  Second, 
I'm not sure we need an  container.  I'd go for an example like, say, so:

http://ietf.org/xml-namesapaces/dmarc-xml/1.0;>
   
  ...
   
   
  ...
   
   http://ietf.org/xml-namesapaces/bimi-xml?/1.0;>
  ...
   
   
  
 ...
  
  
 ...
  
  
 ...
  
 ...
  http://ietf.org/xml-namesapaces/bimi-xml??/1.0;>
 ...
  
   
   
  ...
   



Third, we need to grasp how XML grammars can be composed, and insert it in 
Appendix A.



 At the time, I didn't intend to limit the extensions to IETF-approved 
extensions, though wasn't sure how else this might be used by reporting 
entities (I mentioned domain reputation-ish things during the call).  I'd 
consider that if we don't enforce IETF-registered extensions, the receivers 
could still ignore extensions they don't want to handle.



I assume no one reads the XML directly, except for debugging.  If report 
consumers don't know about an extension, its content will never reach human 
eyeballs.  Extension existence will have to be advertised, and a IANA page 
could be a decent means of doing that.



 I'm also aware this could bloat a report in terms of size, though we've 
already indicated we don't seem overly concerned with the size of the XML body. 
 A few things I'd like to see the group reach consensus on are:

1) Extensions in their own section (as it is now) or within each  element



Both, and both optional.  An extension can have some data to add in some 
, but not necessarily in all of them.



2) Must extensions be IETF-approved



We cannot stop non-registered extensions.  Yet, developers may want to see an 
RFC before implementing code that extracts a given extension's content.



3) If (2) is true, do we want to define any during the DMARCbis process 
(essentially a demonstration of how it is to be done)



It would be a good way to show how to define them.  Not our primary task, 
though.


Best
Ale
--


1: 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4




















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

[dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Brotman, Alex]

Hello folks,

During our interim call last week the topic of extensions within the DMARC 
aggregate report came up.  There was a discussion about how to best introduce 
these, but also how they might be best used.  I noted three cases that I could 
see today; ARC, PSD, and BIMI.   And indeed we have tickets relating to the 
first two.  The original thought was that the aggregate draft would allow a 
place for extensions, and then additional drafts would define those within the 
IETF.  When -02 was originally being worked on, there was a thread about how we 
might like to see this, though not many responses.  The result is in section 4 
of the -02 draft [1]. and I thought we'd enhance that as we progressed.  At the 
time, I didn't intend to limit the extensions to IETF-approved extensions, 
though wasn't sure how else this might be used by reporting entities (I 
mentioned domain reputation-ish things during the call).  I'd consider that if 
we don't enforce IETF-registered extensions, the receivers could still
  ignore extensions they don't want to handle.  I'm also aware this could bloat 
a report in terms of size, though we've already indicated we don't seem overly 
concerned with the size of the XML body.  A few things I'd like to see the 
group reach consensus on are:

1) Extensions in their own section (as it is now) or within each  element
2) Must extensions be IETF-approved
3) If (2) is true, do we want to define any during the DMARCbis process 
(essentially a demonstration of how it is to be done)

Thank you for your continued feedback

1: 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

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