Subject: [marf] Comments about draft-ietf-marf-reporting-discovery

From: Tanguy Ortolo <[email-masked]>
Date: Mon, 14 Mar 2011 18:25:34 +0100

Hello,

I have just read the Internet draft about discovery of willingness to
provide or receive ARF reports. Here are some comments about it.

Section 5, §4:
> In the case of a feedback generator, to inquire whether or not an ADMD
> wishes to receive feedback reports, the DNS domain to which the
> report should be sent is determined (using a mechanism at the
> discretion of the generator)

The goal of this draft being to correct the lack of defined methods in
[MARf-BASE] (cf. section 1, §1), I think it would be appropriate to
define the method for determining the responsible domain name.

In the section 7 this draft refers to [AUTH-METHODS] in way that I
do not understand clearly, but that I interpret as, well, a definition
of such a method. Thus I suggest either:
* to define this method in section 5, refering to [AUTH-METHOD], and to
  remove section 7;
* to replace “(using a mechanism at thediscretion of the generator)” by
  “(using the method defined at Section 7)” and to clarify section 7.

Section 5.2, §2:
> gf the format of reports offered; […]

Feedback reports being an agreement between a producer and a consumer,
it would be impossible to use if both require a different format (though
there is currently only one such format defined). I suggest that the
producer could offer several formats, making this tag a colon-separated
list.  Maybe consumers could offer the choice between several formats
too, but I think it would be less relevant, though I would not be able
to argument it.

And finally, I think that this draft could cover the case where several
entities under a same domain name would require separated reports. In
fact, this would be the same use case as DKIM selectors: example.net has
two entities, admin and marketing, that operate separately and would
like to receive feedback separately. The use of such reporting selectors
could be defined for authentication methods that allow such selectors
(currently only DKIM, I think), and implemented in the exact same way as
DKIM selectors: in my example, that would lead to the DNS records
admin._report.example.net and marketing._report.example.net.

Regads,

-- 
Tanguy Ortolo

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Mar 2011 16:05:58 +0100

>   “(using the method defined at Section 7)” and to clarify section 7.

+1 for the second option.  In facts, since section 7 says what a generator
MUST do, the degrees of "discretion" are somewhat constrained.  As a further
alternative for the parenthesized text, I'd propose

   (choosing, at the discretion of the generator, among the methods
   defined at Section 7)

However, section 7 seems to be overly restrictive.  A generator should be
allowed to send a report to a different domain in some circumstances.  For
example, a RIR might provide a generic reporting address for (some of) its
addresses.

> too, but I think it would be less relevant, though I would not be able

The problem here is that different formats may provide for different report
types.  I think we should order them from most generic to most specialized,
and urge specialized consumers to also accept generic formats, for the sake
of interoperability.  For example, an operator may find it convenient to send
ARF reports, but, if they happen to be involved in IODEF exchanged for
specific cases, they may want to discover the possibility to send that kind
of report to a given consumer.

> admin._report.example.net and marketing._report.example.net.

While it may be possible to define per-selector abuse addresses, abuse
reporting does not depend on DKIM in general.  In addition, the exemplified
use case could be arranged by forwarding reports to the marketing department
based on their DKIM signature.  Such arrangement would still leave to the
admins the possibility to keep an eye on what those guys are actually doing
with their delegation.

jm2c