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

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 2 Oct 2011 08:59:17 -0400

I'm fine with all of Dave's comments, though some of them may be tricky to word correctly.  The one that concerns me most is this one:

> 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?

I definitely want to avoid the redundancy, but I also want the model doc to convey enough information that a fresh reader can figure out what the point is.  I'm sure it can be done, but it may take a few drafts.

I was hoping to get a few more people to comment before I put together another draft.  Can we beat the bushes for more reviewers, perhaps?  -- Nathaniel

On Sep 22, 2011, at 3:03 PM, Murray S. Kucherawy wrote:

>> -----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)
>> 
>> 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.)
> 
> 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.
> 
>> 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.
> 
> That seems a fine substitute.
> 
>> 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?
> 
> That also seems fine, although I realize now I'm volunteering Nathaniel to do this work since he's taking over the -model document.  :-)
> 
>> 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?
> 
> That'd probably be fine.
> 
>> 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.
> 
> 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.
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep