Re: [domainrep] Charter adjustments

[Douglas Otis <[e-mail]>]

On 8/31/11 3:16 PM, Rolf E. Sonneveld wrote:
> On 8/31/11 8:08 PM, Murray S. Kucherawy wrote:
>>> -----Original Message-----
>>> From: Rolf E. Sonneveld [mailto:[e-mail]]
>>> Sent: Wednesday, August 31, 2011 8:43 AM
>>> To: Murray S. Kucherawy
>>> Cc: [e-mail]
>>> Subject: Re: [domainrep] Charter adjustments
>>>
>>> I agree it's a convenient place to begin, but I really fail to see the
>>> added value in the context of a charter document.
>> Charter documents, and BoFs, have to describe the starting point 
>> accurately.  That's why this stuff is in there.
>>
>>> If we want to keep it, may I suggest to slightly change it, to make
>>> more
>>> explicit that these are mere examples, nothing more:
>>>
>>> Old text:
>>>
>>>     * simple -- a reputation is expressed in a simple manner such as
>>>         an integer, provided via TXT records in the DNS
>>>         (see draft-kucherawy-reputation-query-dns)
>>>
>>>     * extended -- a response can contain more complex information
>>>         useful to an assessor, provided via an XML reply over HTTP
>>>         (see draft-kucherawy-reputation-query-http)
>>>
>>>
>>> New text:
>>>
>>>     * simple -- a reputation is expressed in a simple manner, such as
>>>         an integer provided via TXT records in the DNS
>>>         (see draft-kucherawy-reputation-query-dns)
>>>
>>>     * extended -- a response can contain more complex information
>>>         useful to an assessor which, for example, can be provided 
>>> via an XML reply over HTTP
>>>         (see draft-kucherawy-reputation-query-http)
>> That's such a minor change that I've made it.  I see what you're 
>> trying to convey but I don't think it's a very big deal at this point.
>>
>>> What you say here is entirely correct. But that doesn't mean the 
>>> charter
>>> isn't still mixing up the two interpretations of the word 'mechanism'.
>>>
>>> [Granted, I approved the old text, so I presumably didn't notice it 
>>> when
>>> I read the original charter text.]
>>>
>>> Suggestion:
>>>
>>> Old text:
>>>
>>>     Two mechanisms are on the table:
>>>
>>>     [...]
>>>
>>>     The mechanisms will be designed to be application-independent, and
>>>     portable between reputation providers.  The working group will
>>>     consider these and may develop both or decide only one is needed.
>>>
>>> New text:
>>>
>>>     Two combinations of mechanism and reputation data type are on 
>>> the table:
>>>
>>>     [...]
>>>
>>>     The combinations of mechanism and reputation data type will be 
>>> designed
>>>     to be application-independent, and portable between reputation 
>>> providers.
>>>     The working group will consider these and may develop both or 
>>> decide only
>>>     one is needed.
>> This conflates some important things.  Portability is irrelevant to 
>> mechanism, for example; it has to do with the choice of the expressed 
>> reputation (and is thus part of the vocabulary), not the protocol by 
>> which it's delivered.
>>
>> I prefer the current text.
>
> The current text reads "The mechanisms will [...], and portable 
> between reputation providers". In your answer to my mail you write: 
> "Portability is irrelevant to mechanism". Ergo?
The path to hell is paved with good intentions.  Why establish 
potentially detrimental mechanisms based on abstract methods using 
flawed examples?

When an underlying identity mechanism might harm networks or incorrectly 
identify responsible actors, any such scheme should be dissuaded.

Aggregation of poorly considered mechanisms will not mitigate possible 
harm, but will eliminate possible redress.  This effort will not 
establish the desired outcome.   It is unwise to assume the outcome of 
such a system is not affected by inherent weaknesses.  Examples given in 
this charter illustrate very poor judgement with respect to identify 
mechanisms that are open to abuse.

-Doug