On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis wrote:
>
> When the REPUTE list first started, I commented about DKIM's inability to
> support fair reputation, and about 1 year ago, and then again a few months
> ago IIRC. These comments were ignored with some denouncement appearing in
> other venu
Hi Tony, thanks for the review. Apologies for the long delay replying.
On Fri, Aug 30, 2013 at 7:46 AM, Tony Hansen wrote:
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/
On Aug 30, 2013, at 7:50 PM, Andrew Sullivan wrote:
> Colleagues, and Doug especially,
>
> The message I sent (below) wasn't intended as a "shut up and go away"
> message, but a genuine query. I have grave doubts that TLS is the
> right example (to begin with, I think fitting it into the REPUT
Colleagues, and Doug especially,
The message I sent (below) wasn't intended as a "shut up and go away"
message, but a genuine query. I have grave doubts that TLS is the
right example (to begin with, I think fitting it into the REPUTE
approach, given the existing CA structure, would also be
contro
Hello,
After reading the reviews of the Application Area Directorate review
it seems to me that there is some misunderstanding of what an
Application Area Directorate review is about. The review is to give
the Applications Area Directors a sense of how important it is that
they pay attention
Hi Doug!
On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote:
> Use of DKIM offers a very poor authentication example
Thanks for the feedback. I don't recall you having made this point on
the repute mailing list. Did you, & I missed it?
Do you have a better example, specifically excl
Dear Tony,
Use of DKIM offers a very poor authentication example, since this draft makes
the same errors made in RFC5863. It is wrong to suggest the DKIM protocol
permits associating a validated identifier to a message as stated in the
Introduction. This is the same erroneous conflation of a
On 8/30/2013 2:37 PM, Hector Santos wrote:
> On 8/30/2013 10:46 AM, Tony Hansen wrote:
>>
>> The document describes a model for reputation services, particularly
>> those being produced by the Repute WG. It follows the recommendations
>> of RFc4101 for describing a protocol model, which requires an
On 8/30/2013 4:09 PM, Andrew Sullivan wrote:
On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
archives of the Repute WG to find or extract these very real and
practical integration considerations. The document should have
these general considerations summarized.
But your sugges
On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
> archives of the Repute WG to find or extract these very real and
> practical integration considerations. The document should have
> these general considerations summarized.
But your suggestion was for protocol-specific advice. I d
On 8/30/2013 10:46 AM, Tony Hansen wrote:
The document describes a model for reputation services, particularly those
being produced by the Repute WG. It follows the recommendations of RFc4101 for
describing a protocol model, which requires answers to 1) the problem the
protocol is trying to
Hi Andrew,
I think it can be generalized functional description without
specifics. Designs based on REPUTE and its users of such products,
will need some information. That may come (hopefully) from the REPUTE
product designer. I am suggesting to remind such future REPUTE product
designers of
On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
>
> For example, DKIM-REPUTE product designers would need to consider
> SPF reputons product models. Simple text as follows can resolve the
> integration consideration with little SPF fanfare the draft
> obviously tried to avoid:
Why
On Fri, Aug 30, 2013 at 12:20 PM, Andrew Sullivan
wrote:
> On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
> > For example, DKIM-REPUTE product designers would need to consider
> > SPF reputons product models. Simple text as follows can resolve the
> > integration consideration wi
I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
Please resolve these comments along with any other Last Call comments you may
receive. Please wait
15 matches
Mail list logo