Subject: [domainrep] Charter adjustments

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 30 Aug 2011 22:32:14 -0700

After some review by our sponsoring AD, I've made a few tweaks in the proposed charter.  Please provide any comments you may have, even if it's just a "looks good", preferably sooner rather than later.  They are pretty minor, but having such feedback on the record will help move things along.

The full updated charter is still available at http://www.blackops.org/~msk/domainrep/repute-charter.txt; the diffs are below.

Absent any major problems, we should be on an IESG telechat and the main IETF mailing list fairly soon.

-MSK

--- repute-charter	2011/08/14 02:52:38	1.16
+++ repute-charter	2011/08/29 22:05:44
@@ -74,16 +74,19 @@
 
 	This working group will produce a set of documents defining and
 	illustrating the requirement and defining mechanisms to satisfy it.
-	Two mechanisms are proposed:
+	Two mechanisms are on the table:
 
 	* simple -- a reputation is expressed in a simple manner such as
-		an integer
+		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
+		useful to an assessor, provided via an XML reply over HTTP
+		(see draft-kucherawy-reputation-query-http)
 
 	The mechanisms will be designed to be application-independent, and
-	portable between reputation providers.
+	portable between reputation providers.  The working group will
+	consider these and may develop both or decide only one is needed.
 
 	The group will also produce specifications for reporting reputation
 	data from end-points (usually end users, such as someone clicking @@ -128,6 +131,14 @@
 	  compute reputations.  These are part of a back-end system, usually
 	  proprietary, and not appropriate for specification as part of
 	  a query/reply framework and protocol.
+
+	The initial draft set:
+		draft-kucherawy-reputation-model
+		draft-kucherawy-reputation-media-type
+		draft-kucherawy-reputation-query-http
+		draft-kucherawy-reputation-query-dns
+		draft-kucherawy-reputation-query-udp
+		draft-kucherawy-reputation-vocab-identity
 
 Goals and Milestones:
 	Mar 2012:	Informational document, defining the problem space

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 31 Aug 2011 10:28:25 +0200

Hi, Murray,

> +++ repute-charter	2011/08/29 22:05:44

Does the 'such as' exclude alternative simple mechanisms which do not 
work via TXT records in DNS? Or is 'provided via TXT records in the DNS' 
just given as an example? On other words, does 'such as' relate to only 
'an integer' or to the entire phrase?

> +		(see draft-kucherawy-reputation-query-http)

Same question as above: does this limit in-charter discussions to the 
mechanism described in the draft document?

> +	consider these and may develop both or decide only one is needed.

Hmm, IMHO retrieval mechanisms (simple vs extended) and types of 
reputation data (simple vs complex) are mixed up here. If I remember 
correctly we discussed the 'application independence' and 'portability' 
in the context of the reputation data, not the (retrieval) mechanism. 
The portability of the reputation data is important as this data can be 
interchanged between reputation providers and consumers can use 
different reputation sources and may want to compare or aggregate 
reputation scores. The portability and application independency of the 
retrieval mechanism doesn't need to be mentioned here, as it is implicit 
to the creation of a standards track RFC.

All in all, I'm not convinced the new charter text is an improvement 
over the old one.

/rolf

---

From: Johan Pouwelse <[email-masked]>
Date: Wed, 31 Aug 2011 12:13:31 +0200

"looks good"

 -johan.

On 31/08/2011, Murray S. Kucherawy <[email-masked]> wrote:
> After some review by our sponsoring AD, I've made a few tweaks in the
> proposed charter.  Please provide any comments you may have, even if it's
> just a "looks good", preferably sooner rather than later.  They are pretty
> minor, but having such feedback on the record will help move things along.
>
> The full updated charter is still available at
> http://www.blackops.org/~msk/domainrep/repute-charter.txt; the diffs are
> below.
>
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 08:00:14 -0400

> After some review by our sponsoring AD, I've made a few tweaks in the proposed charter.  Please provide any comments you may have, even if it's just a "looks good", preferably sooner rather than la…

I'm fine with this, although this change

> +	Two mechanisms are on the table:

seems to me to be in the wrong direction.  I increasingly hate the
hoary phrase "on the table".

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 07:00:02 -0700

> -----Original Message-----
> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Wednesday, August 31, 2011 1:28 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [domainrep] Charter adjustments
> 

It indicates a starting point for discussion.  The use of DNS TXT records to relay data is controversial and I expect we'll have that debate, but it's a convenient place to begin.

> mechanism described in the draft document?

Same answer; it's a good starting point.  The debate here doesn't seem to be over HTTP, but rather over JSON vs. XML.  But, of course, HTTP could also be debated.

> in the context of the reputation data, not the (retrieval) mechanism.

We discussed both.  The former goes in the "model" and "media-type" documents; the latter goes in the two protocol specifications.

> All in all, I'm not convinced the new charter text is an improvement

I'm curious as to why, since this is text you previously approved:

http://www.ietf.org/mail-archive/web/domainrep/current/msg00418.html

The only real change is that the initial examples of "simple" and "extended" are given explicitly, rather than only in the drafts that have already been posted.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 31 Aug 2011 17:42:58 +0200

> It indicates a starting point for discussion.  The use of DNS TXT records to relay data is controversial and I expect we'll have that debate, but it's a convenient place to begin.

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.

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)

> We discussed both.  The former goes in the "model" and "media-type" documents; the latter goes in the two protocol specifications.

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.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 31 Aug 2011 16:00:30 -0000

>hoary phrase "on the table".

It's also confusing.  In the US, a motion that is tabled is set aside
and will probably never be seen again.  In the UK and Canada, a motion
that is tabled is taken up for active debate.

I'm happy with "proposed" or "under consideration", or any similar
furniture-free non-metaphorical term.

I'm also OK with the TXT and XML-HTTP examples, given that they're
examples.  It seems easier than "a query mechanism intended to be
sufficiently lightweight to be implemented as a single UDP round trip
with possible intermediate caches", and "a query mechanism using a
hierarchical naming scheme and returning a potentially large response
containing tagged data in an agreed format."

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 10:53:35 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, August 31, 2011 9:01 AM
> To: [email-masked]

OK, I've gone back to "under consideration".

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 11:08:21 -0700

> Sent: Wednesday, August 31, 2011 8:43 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Charter documents, and BoFs, have to describe the starting point accurately.  That's why this stuff is in there.

> 		(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.

> 	The working group will consider these and may develop both or decide only

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.  Is there other feedback?

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 01 Sep 2011 00:16:47 +0200

On 8/31/11 8:08 PM, Murray S. Kucherawy wrote:
> 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?

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Wed, 31 Aug 2011 16:30:48 -0700

On 8/31/11 3:16 PM, Rolf E. Sonneveld wrote:
>> Charter documents, and BoFs, have to describe the starting point 
>> accurately.  That's why this stuff is in there.
>>
>> 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.
>>
>> 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.
>>
> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Aug 2011 16:34:55 -0700

> Sent: Wednesday, August 31, 2011 3:17 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I think I see what you're getting at now.  How's this:

        Both the syntactical and semantic aspects of these 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.