Subject: [domainrep] Comments on -model-00 (full set)

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Sep 2011 15:48:17 -0700

(oops.  left off two more comments...)

On the current -model-00 document:

1.  By citing the related documents, you make the publication of this document 
be gated on their being published first.  That's the reason I'm not a fan of 
"forward" pointers like this. (It only gets worse as more documents list the 
component set.)

In contrast citing functional divisions, without citing specific documents, lays 
the groundwork with no gating.  The later documents, of course, can have a 
backward reference that declares which function(s) from the set they cover.

The current 'model' is for the localized mechanism, without reference to the 
larger, systemic framework for identification and assessment that this piece 
fits into.  Figure 1 (RFC 5863) and Figure 1 (RFC 5585) attempt the sort of 
full-system description.  I suggest that the model document, here, should deal 
with the full architecture, so that it's clear where the current work fits into 
a true, end-to-end email service.  If any of the existing diagrams and 
discussion are sufficient, just cite them.  If they need elaboration, perhaps 
build on them?

In any event, I do suggest a separate diagram for the pieces that the model 
covers, to show their relationships.

2. Potential redundancy and synchronization challenges.

Section 4 lists information components.  I suspect that that is a redundant list 
with the media-type document and will need to be synchronized.  Every change 
requires updating two documents...  Perhaps the model document can be restricted 
to discussion of core issues about a media-type rather than going into details?

3. Bias

I like the intent of Section 7.1 but suspect it lays a trap for itself.  Opinion 
is, by its definition, biased.  Objectivity when making an assessment of 
quality, is really about process and not conclusion.

I suspect the real issues are transparency about criteria and consistency in 
their application.  That's not quite the same thing as being unbiased.

An essential point about the proposed work is that it has nothing to do with the 
basis for choosing criteria nor with the way in which they are applied.  It does 
permit listing underlying information, which can aid transparency.

But fundamentally it is about representing and obtaining data in a standardized 
way, rather than assessing its merits.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 22 Sep 2011 12:03:23 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, September 12, 2011 3:48 PM
> To: [email-masked]
> Subject: [domainrep] Comments on -model-00 (full set)
> 

Originally, I fully expected this to exit the working group as a document cluster.  I'm less convinced now though.

I'd be fine removing that chunk from all the documents.

> backward reference that declares which function(s) from the set they

That seems a fine substitute.

> discussion are sufficient, just cite them.  If they need elaboration, perhaps

That also seems fine, although I realize now I'm volunteering Nathaniel to do this work since he's taking over the -model document.  :-)

> to discussion of core issues about a media-type rather than going into

That'd probably be fine.

> way, rather than assessing its merits.

I think the point is to be clear about what the report is trying to say and how certain the reporter is about the claim being made.   Requesting reputation about example.com, with no other parameters, leaves the requesting entity in a position where it must assume what the reply means, or must request a detailed reply that allows it to confirm such an understanding; the reputation of example.com when used in DKIM signatures might be different that the reputation of example.com when delivered by SPF.

The assumption (which is necessary for the lightweight query) means the requesting entity already has a good understanding of what the data mean.  Perhaps the reputation service it's querying has declared that it only produces reputations based on DKIM signatures, or something like that, so the additional detail isn't needed.

The heavyweight query on the other hand is structured that it can say something like "reputation of example.com is X when based on DKIM".

What came up in the BoF was the need for transitivity, so that if you want to change reputation providers within the email space, you don't have to worry that a 0.5 from provider A means something totally different than it would from provider B (say, one of them is linear while the other is logarithmic).  But I think that goes in the specific vocabulary documents, though the general concept can be introduced in the model document.