Subject: [apps-discuss] On "supporting the publication of this document"

From: Pete Resnick <[email-masked]>
Date: Mon, 9 May 2011 19:09:57 -0500

[Starting with Apps Discuss; maybe I'll post this on the IETF list at 
some point.]

Philosophical thought for the day:

During last call, I occasionally see comments to the effect of, "I have 
read and support the publication of this document." I have to say that, 
as one of the people who has to judge consensus on a document, I find 
these statements...well...useless. Kind of like cotton candy (or "candy 
floss" or "fairy floss" to some of you): Sweet, but completely without 
substance. If you don't tell me *why* you "support publication of the 
document" (e.g., "I think the solution proposed is the right one", or 
"the solution stinks, but it's the only one we have"), then I have no 
way to judge consensus on the *content* of the document. If all you mean 
is that you have no objection to the *content* document, a much better 
formulation would be, "I've read this document. There's nothing in here 
I disagree with, and it doesn't impact any other protocol I care about." 
But without explanation, I have to assume that the reason you "support 
publication" is because you have a wager on how soon we will get to RFC 
10000. :-)

Objections to the *content* of a document are extremely important to hear.
Support of or rebuttal to objections to the *content* of a document are 
very important to hear.
Claims that the *content* of the document solves a problem for you are 
good to hear.
Asserting that you have no objections to the *content* of a document is 
of some interest.
Commentary on the *publication* itself is, really, truly, not important.

OK, back to real work.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: SM <[email-masked]>
Date: Mon, 09 May 2011 23:58:09 -0700

Hi Pete,
At 17:09 09-05-2011, Pete Resnick wrote:
>During last call, I occasionally see comments to the effect of, "I 
>have read and support the publication of this document." I have to 
>say that, as one of the people who has to
>judge consensus on a document, I find these 
>statements...well...useless. Kind of like

Can I +1 instead? :-)

>cotton candy (or "candy floss" or "fairy floss" to some of you): 
>Sweet, but completely without substance. If you don't tell me *why* 
>you "support publication of the document" (e.g., "I think the 
>solution proposed is the right one", or "the solution stinks, but 
>it's the only one we have"), then I have no way to judge consensus 
>on the *content* of the document. If all you mean is that you have 
>no objection to the *content* document, a much better formulation 
>would be, "I've read this document. There's nothing in here I 
>disagree with, and it doesn't impact any other protocol I care 
>about." But without explanation, I have to assume that the reason 
>you "support publication" is because you have a wager on how soon we 
>will get to RFC 10000. :-)

Telling you why I support publication of a document requires:

  (i)  Thinking

  (ii) Reading the previous comments to avoid restating the same points

BTW, your note touches any interesting topic, i.e. how to judge consensus.

>Support of or rebuttal to objections to the *content* of a document 
>are very important to hear.
>Claims that the *content* of the document solves a problem for you 
>are good to hear.
>Asserting that you have no objections to the *content* of a document 
>is of some interest.

Explain what problem the document solves for you.  Avoid ambivalent 
statements as far as possible as they will be misunderstood in 99.7% 
percent of cases.

>Commentary on the *publication* itself is, really, truly, not important.

I don't understand the above sentence.

Regards,
-sm

---

From: "" <[email-masked]>
Date: Tue, 10 May 2011 10:32:44 +0100

------- Original message -------
> From: Pete Resnick <[email-masked]>
> To: [email-masked]
> Sent: 10.5.'11,  1:09
>
> read and support the publication of this document."

I have read and support the sending of this email message.

---

From: John Leslie <[email-masked]>
Date: Tue, 10 May 2011 07:31:18 -0400

> I have read and support the sending of this email message. 

   Exactly!

   ;^)

   (I always thought the purpose of such LastCall comments was to keep
folks like me from pointing out too many flaws in the spec... ;^)

--
John Leslie <[email-masked]>

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 May 2011 09:33:02 -0400

On Mon, May 9, 2011 at 20:09, Pete Resnick <[email-masked]> wrote:
> During last call, I occasionally see comments to the effect of, "I have read
> and support the publication of this document." I have to say that, as one of
> the people who has to judge consensus on a document, I find these
> statements...well...useless.

+1 :-)

I find allowing responses like that to count to be vulnerable to flash
crowd invasions, political or competitive manipulation, etc.  I prefer
at least one original, substantive sentence about why.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 May 2011 07:45:08 -0700

On 5/9/2011 5:09 PM, Pete Resnick wrote:
> [Starting with Apps Discuss; maybe I'll post this on the IETF list at some point.]
>
> During last call, I occasionally see comments to the effect of, "I have read and
> support the publication of this document." I have to say that, as one of the
> people who has to judge consensus on a document, I find these

For the last twenty years, I've understood that one of the IESG essential 
questions for a Last Call is whether anyone cares about the document being 
considered for publication.  It well could be of interest to a few die-hard 
protocol specifiers, but no one else in the industry, and it used to be that 
broad support was a criterion.

During my own time as an AD, long ago, this question was explicit within the 
IESG and simple statements of support were helpful for answering it.

Is this no longer a concern?

Your note suggests that, at the least, the text of a Last Call should make much 
more clear what sorts of comments are being sought (and why and probably from 
whom.)  The community should not have to guess what sorts of responses are 
useful for the IESG.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 May 2011 11:32:11 -0500

On 5/10/11 9:45 AM, Dave CROCKER wrote:

>> have read and
> For the last twenty years, I've understood that one of the IESG 
> essential questions for a Last Call is whether anyone cares about the 
> document being considered for publication.  It well could be of 
> interest to a few die-hard protocol specifiers, but no one else in the 
> industry, and it used to be that broad support was a criterion.
>
> During my own time as an AD, long ago, this question was explicit 
> within the IESG and simple statements of support were helpful for 
> answering it.
>

It is a concern, but see Scott and SM's notes: Saying "I have read and 
support the publication of this document" is indistinguishable from, "My 
co-worker/friend/third-cousin-twice-removed told me I should send in a 
message supporting this document, so I did." All I'm saying is that 
additional text indicating *why* you support this document is the 
important part. Your statement of support is, in and of itself, 
relatively uninteresting.

> Your note suggests that, at the least, the text of a Last Call should 
> make much more clear what sorts of comments are being sought (and why 
> and probably from whom.)

Nope. I'm interested in any and all substantive comments. The problem 
with "I support the document" is that I can't tell whether it's 
substantive without me asking more questions and the sender doing a bit 
more writing. Sometimes I have enough context (long-time contributor to 
the group says so), but if I've got that context, then I probably know 
*why* they are saying that. (Generally, long-time contributors say, "I 
think the document is ready" rather than "I support its publication".) 
But its probably better to not assume that the reader has the context 
and explain your support.

> The community should not have to guess what sorts of responses are 
> useful for the IESG.

I am not clear on what guessing you think is involved.

pr

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 May 2011 11:13:44 -0700

On Tue, May 10, 2011 at 9:32 AM, Pete Resnick <[email-masked]> wrote:

> additional text indicating *why* you support this document is the important
> part. Your statement of support is, in and of itself, relatively
> uninteresting.
>
>
>
To put this slightly differently, a statement of support where the AD has no
context is hard to evaluate.  For some people, the AD's knowledge of the
individual is the context.  If Steve Bellovin says he has read and supports
a security document, the AD's knowledge of Steve's history in that space is
probably context enough.  IF you know the individual, in other words, you
know whether they are really speaking for themselves or the
cousin-twice-removed.  But this has some bad scaling problems.

Having someone say something like "I plan to implement this, and I think the
document is good enough for me to do so" or "I have implemented this" is
more data than "I think this is good".   Having them say "This answers
problem FOO which I face, so I will be pointing my vendors to this as a
requirement" is similar.   Saying "I support this over proprietary solution
BAR" hints that the reason is the individual prefers a standards-based
approach to a proprietary one, but it would be even better if they made that
explicit.

Consensus as "no objections heard" is a fine thing, and it is often enough.
We can assume that the original impetus to the work is just carrying through
to delivery.  But when an AD (or the IESG) is trying to gauge whether their
own possible objections should be treated as the rough part of the rough
consensus, concrete statements help a lot.

Just my two cents, of course,

Ted

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 May 2011 15:46:05 -0400

> part.

And you really think that my TCTR couldn't tell me I should send a
message saying that I think the document is valuable and clear, and
that I could implement from it?  Or whatever?

And you really think that if Dave says the document is valuable and
clear, and that he could implement from it, and that's the same thing
*I* wanted to say, I shouldn't just say "+1", or "I agree"?

As I said in my off-list note to you, simply the fact that I read the
document (or, at least, claimed to) and took the time to send a
comment should be enough to give you valuable information -- it's
absolutely NOT "useless".  I appreciate that you might *also* like
more than that, and if I have more than that to say, I will.  But the
idea that the IESG might ignore such comments as "useless" gives me
more than a bit of fright.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Tue, 10 May 2011 15:51:35 -0500

On 5/10/11 2:46 PM, Barry Leiba wrote:
>> Saying "I have read and

Well, your cousin could try to tell you how to do that. But it gets 
harder for people to pull this off with a straight face if, as a group, 
we start giving more elaborate comments. People who are normal 
participants in the group start asking the right kinds of questions of 
those folks and they get marginalized.

But getting rid of process abusers is only a secondary goal here. Really 
my point is, I want us all to get in the habit of taking responsibility 
for documents; to not assume that the AD is going to be the final 
backstop, but instead assuming that the AD may be a dope and needs this 
stuff explained to him or her.

> *I* wanted to say, I shouldn't just say "+1", or "I agree"?

cf. Ted's comment about context. I might take you or Dave as saying 
something more interesting because I have a context of who you are. And 
given that context, you or Dave might well say, "(*grunt*)" instead of 
"I support the document", because really I'm not judging consensus on 
what you say, but on the context entirely. (That's what I mean by the 
statement being "useless".) But grunts and dependence on context makes 
it really difficult for new folks to know what's going on (be they ADs, 
chairs, or just participants), and it sets up the idea that what we're 
doing here is voting rather than coming to consensus. So if that means 
that folks we know well all have to add a sentence or two more during LC 
to set a good example, I'm OK with that.

> more than a bit of fright.

Of course the "or, at least, claimed to" is exactly what gives me a bit 
of fright. But understand that I really *might* ignore comments that 
come without context because there really is no way to evaluate what 
they mean. I'd rather get a bit of extra context. That makes it easier 
to point to later.

pr

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 May 2011 15:10:17 -0600

On 5/10/11 8:45 AM, Dave CROCKER wrote:

> and probably from whom.)  The community should not have to guess what
> sorts of responses are useful for the IESG.

FWIW, over in the XMPP Standards Foundation (xmpp.org) we ask the
following questions in each of our Last Call announcements:

#    Please consider the following questions during this Last Call and
#    send your feedback to the [email-masked] discussion list:
#
#    1. Is this specification needed to fill gaps in the XMPP
#       protocol stack or to clarify an existing protocol?
#    2. Does the specification solve the problem stated in the
#       introduction and requirements?
#    3. Do you plan to implement this specification in your code?
#       If not, why not?
#    4. Do you have any security concerns related to this specification?
#    5. Is the specification accurate and clearly written?

Whether that's the right set of questions is another issue...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 May 2011 15:35:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, May 10, 2011 2:10 PM
> To: [email-masked]
> Cc: Pete Resnick; [email-masked]
> Subject: Re: [apps-discuss] On "supporting the publication of this document"
> 

This, and especially that last one, makes it sound like a PROTO write-up.  Are you sure you want that from a potentially huge list of people?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 May 2011 21:15:19 -0400

> This, and especially that last one, makes it sound like a PROTO write-up.
> Are you sure you want that from a potentially huge list of people?

Interesting: I think the last question is the *most* important, and
the one that *least* seems like it came out of a PROTO write-up.  Yes,
that's the question I *do* most want to see *all* reviews answer.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 May 2011 19:26:51 -0600

> This, and especially that last one, makes it sound like a PROTO write-up.  Are you sure you want that from a potentially huge list of people?

Well, that's what we ask at xmpp.org. I'm not suggesting that we do so
at ietf.org. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 May 2011 08:26:49 -0700

On 5/10/2011 2:10 PM, Peter Saint-Andre wrote:
>> Your note suggests that, at the least, the text of a Last Call should make
>> much more clear what sorts of comments are being sought (and why and
>> probably from whom.)  The community should not have to guess what sorts of
>> responses are useful for the IESG.
>
> FWIW, over in the XMPP Standards Foundation (xmpp.org) we ask the following
> questions in each of our Last Call announcements:

It has the considerable benefit of guiding the respondent to provide pragmatic
detail.

The IETF would do well to include some form of similar guidance in its Last Call
announcement.

n 5/10/2011 6:15 PM, Barry Leiba wrote:
>>> #    Please consider the following questions during this Last Call and #
>>> send your feedback to the [email-masked] discussion list: # #    1.
>>> Is this specification needed to fill gaps in the XMPP #       protocol
>>> stack or to clarify an existing protocol? #    2. Does the specification
>>> solve the problem stated in the #       introduction and requirements? #
>>> 3. Do you plan to implement this specification in your code? #       If
>>> not, why not? #    4. Do you have any security concerns related to this
>>> specification? #    5. Is the specification accurate and clearly
>>> written?
>>>
> Interesting: I think the last question is the *most* important, and the one
> that *least* seems like it came out of a PROTO write-up.  Yes, that's the
> question I *do* most want to see *all* reviews answer.

Whereas I think each of these questions is quite important, with the last one
likely to get the most pro-forma responses, since it is the most difficult to
answer knowledgeably.

> On 5/10/2011 3:35 PM, Murray S. Kucherawy wrote:
...
>> Are you sure you want that from a potentially huge list of people?

I don't see a problem with having a potential large number of people supply 
detailed responses.  (For one thing, I doubt that the typical case is/will be a 
large number...)

d/

-- 

   Dave Crocker

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 May 2011 11:35:21 -0400

On Wed, May 11, 2011 at 11:26, Dave CROCKER <[email-masked]> wrote:
> It has the considerable benefit of guiding the respondent to provide
> pragmatic detail.
>
> The IETF would do well to include some form of similar guidance in its Last
> Call announcement.

> detailed responses.  (For one thing, I doubt that the typical case is/will
> be a large number...)

Glad to hear it.  I couldn't tell where you were headed.

Scott

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 May 2011 18:00:28 +0100

Dave CROCKER wrote:

>> following
> pragmatic

+1.

> On 5/10/2011 6:15 PM, Barry Leiba wrote:
>
>> the one

+1.

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 May 2011 16:37:00 -0400

--On Tuesday, May 10, 2011 15:46 -0400 Barry Leiba
<[email-masked]> wrote:

>...
> As I said in my off-list note to you, simply the fact that I
> read the document (or, at least, claimed to) and took the time
> to send a comment should be enough to give you valuable
> information -- it's absolutely NOT "useless".  I appreciate
> that you might *also* like more than that, and if I have more
> than that to say, I will.  But the idea that the IESG might
> ignore such comments as "useless" gives me more than a bit of
> fright.

Barry,

>From my point of view, Pete is being explicit, and offering to
be consistent, about something that, to some degree, I think
most ADs do at one thing or another.    Both "explicit" and
"consistent" are good, at least IMO.  In less explicit form, ADs
figure out that, in measuring consensus about the technical
quality of a document, its interactions (or lack thereof) with
other work and protocols, etc., informed opinions from experts
who have studied a document carefully are simply worth more
than, to state the extreme case, endorsements from the clueless.
Most of the time (I hope), when the IESG is doing a technical
evaluation, they are looking at comments and criticisms
(positive or negative), not counting the number of those
comments.  One well-reasoned analysis that identifies a
persuasive showstopper should, and usually does, stop a document
until the problem is remedied no matter how many people say "I
didn't notice any problems".  Worse (and this is where my view
aligns with Ted's "context" comments), unless the practical
definition of "expert" is "someone whom the AD already considers
an expert", people need to give the AD a clue that their
comments should be taken seriously and the best clue is a
carefully-written review statement.  By contrast, "I like it"
isn't a very good clue, one way or the other.

A distinction I don't think Pete made is that the IESG is called
upon to evaluate and determine consensus, not just about
technical quality and relationships, but about interest (and,
ideally, commitment).  Those two determinations are almost
orthogonal.  For the purpose of determining consensus about
interest, a statement such as "I like this and think it should
be published" is actually very helpful, especially for a non-WG
document (for a WG document, there is a presumption of interest
and commitment that arises from getting chartered).  

So, I wouldn't have said "useless".  I might have said "of very
limited value in helping the IESG with its determination of
consensus about technical quality and adequacy of review".

   john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 May 2011 17:06:35 -0400

> comments.

OK.  I hadn't looked at Pete's comments that way, and I certainly
agree with this.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 May 2011 14:10:02 -0700

On 5/10/2011 1:51 PM, Pete Resnick wrote:
> But getting rid of process abusers is only a secondary goal here. Really my
> point is, I want us all to get in the habit of taking responsibility for
> documents; to not assume that the AD is going to be the final backstop, but
> instead assuming that the AD may be a dope and needs this stuff explained to him
> or her.

Your original line of comment started with the negative of what you aren't 
lokking for.  I think this whole discussion gets much more constructive by 
starting with a statement like the above.  It says what you /are/ looking for, 
and it declares a goal with a broad, basic benefit.

Taking responsibility requires establishing one's involvement.  Within an 
on-going working group discussion, a context exists and a "+1" is an efficient 
tool within that.  (Note that a review tends to start with a factual summary of 
what is being reviews; this establishes that the reviewer has enough 
understanding to offer an opinion.)

For a Last Call, there typically is no such context for most of the folk 
submitting an opinion. Therefore, each person submitting an opinion should 
assume that the first requirement is to establish the basis for their 
involvement, knowledge, interest, or the like in the paper.

No doubt there are a few IETF Well-Known Culprits (WKC) who might respond to one 
person's posting by just adding a +1, and the rest of us will know how to 
interpret it.  But that's a poor rule for general commenting.  (That is, a +1 
for a LC makes sense if you are a WKC and know you are...)

d/
-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 May 2011 17:07:52 -0500

On Wed, May 11, 2011 at 4:10 PM, Dave CROCKER <[email-masked]> wrote:
> on-going working group discussion, a context exists and a "+1" is an
> efficient tool within that.  (Note that a review tends to start with a
> factual summary of what is being reviews; this establishes that the reviewer
> has enough understanding to offer an opinion.)
>

I assume you mean an IETF LC, not WG LC here.

> involvement, knowledge, interest, or the like in the paper.

I worry that this approach will lead to an obnoxious level of
formalism (a formalism that may be quite fine for lists like secdir),
where reviewers start their comments with:

"I have read I-D draft-....  My comments are below.  My background
is...  I'm interested in this work for the following reasons...  Blah,
blah, blah."

Seems a bit much.

Good technical opinions are good regardless of the speaker.

I'm not sure I care to see each commenter establish the basis for
their involvement, etcetera.  There are anonymous and pseudonymous
participants too, and I don't really care to ignore them for being so,
or to force them to disclose information about themselves that they
might wish to keep private.  New or infrequent participants should be
encouraged to make some such statements provided they are comfortable
doing so.

It's one thing to ask for more substantive statements than "I support
publication", and quite another to ask for people to establish their
bonafides (something we've never really done at the IETF merely for
participating).  I oppose the latter.  But even the former seems a bit
much wherever it means effectively repeating what has already been
stated.  "+1" is concise, and depending on context can also be quite
precise.  There's no need to be exceedingly verbose (and now I must
watch the length of this reply).

> No doubt there are a few IETF Well-Known Culprits (WKC) who might respond to
> one person's posting by just adding a +1, and the rest of us will know how
> to interpret it.  But that's a poor rule for general commenting.  (That is,
> a +1 for a LC makes sense if you are a WKC and know you are...)

If there's any doubt one can always ask for clarification.  ISTM that
the best thing to do is to ask *in the LC announcement* for
substantive statements of support or opposition, and that any "+1"s or
"me too"s be clear as to what's being agreed to.

Nico
--

---

From: "t.petch" <[email-masked]>
Date: Thu, 12 May 2011 09:25:19 +0200

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 10, 2011 10:51 PM
> stuff explained to him or her.

I didn't realise you were writing this in the role of AD but, even so,
I think that you are wrong.  I never used to post messages to say that I
had read and supported the advancement of an I-D, but, increasingly,
I see plaintive notes from WG Chairs to the effect that nothing is going
to happen unless and until someone posts something, and that a note
saying 'I have read and support this document' is helpful.

So I have started posting such notes and will continue to do so
(although I usually manage to point out a few grammatical errors at
the same time).  If ADs do not want to see them - tough - you
will just have to black list my mail:-)

WG Chairs will normally have had the opportunity to recognise my
e-mail address since, normally, I will have participated in the
discussions beforehand.  Perhaps the problem with ADs is that
they do not have the time to follow the mail list discussions as
much as they might and so are not familiar with the posters.

Tom Petch

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 May 2011 08:52:55 -0700

On 5/11/2011 3:07 PM, Nico Williams wrote:
> formalism

The IETF has quite a bit of formalist, along with it's famously having quite a 
bit of informality.  When introducing rules, the challenge for us is to get it 
right.  That's why we need to be careful that our formality, here, is about the 
/nature/ of what is provided and not the form.  (We often get this confused, of 
course...)

For establishing credibility, the need is to say enough to show actual knowledge 
of the document, not to regurgitate a CV.

> Good technical opinions are good regardless of the speaker.

Indeed they are, but providing enough information to know that they are good is 
the issue here.

For example, compare:

      This document specifies a technique that won't scale.

versus:

      I have worked on the design of a number of protocols that have become 
popular for wide-scale use on the Internet, namely xxx, yyy and zzz.  I've also 
worked on a number that failed to gain popularity, namely aaa and bbb.

      Based on this experience I believe this document specifies a technique 
that won't scale.  In particular, the foo mechanism requires manual updating, 
which is extremely expensive and error prone.

So, which bit of input would you expect to be more useful when making a decision 
about the documenet?

d/
-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 12:24:20 -0500

On Thu, May 12, 2011 at 10:52 AM, Dave CROCKER <[email-masked]> wrote:
> The IETF has quite a bit of formalist, along with it's famously having quite
> a bit of informality.  When introducing rules, the challenge for us is to
> get it right.  That's why we need to be careful that our formality, here, is
> about the /nature/ of what is provided and not the form.  (We often get this
> confused, of course...)

Well, I prefer formalism for specifications, and informality for the
social aspects of standards-setting.  We could argue about both till
the cows come home.  As long it's personal preferences that we're
stating then there's no need to argue about these.  But regarding
bonafides establishment, I have fairly strong feelings here:

> For establishing credibility, the need is to say enough to show actual
> knowledge of the document, not to regurgitate a CV.

Sure, this may be _advisable_ for non-usual-suspects, and occasionally
advisable for usual suspects (namely: when necessary as a result of
participation by new participants).  (I don't really care for a lot of
tedious repetition.)  But I've grave reservations about this as a
formal part of argument at the IETF (see below).

> Indeed they are, but providing enough information to know that they are good
> is the issue here.

When there's reason to doubt a statement, yes.  But it's not always
necessary.  For example, a person I rarely see posts from posted to
KRB-WG the other day to point out a security flaw in one PKINIT
variant.  The flaw was obvious once described.  There was no need for
the poster to describe their experience, nor should there have been.
You give an example where I can imagine that the poster's experience
will contribute weight to the statement, but the statement will need
to be explored in detail in such a case anyways, and I still wouldn't
really care what the poster's experience was once we're done
establishing the value of that statement:

> popular for wide-scale use on the Internet, namely xxx, yyy and zzz.  I've
> also worked on a number that failed to gain popularity, namely aaa and bbb.
>
> that won't scale.  In particular, the foo mechanism requires manual
> updating, which is extremely expensive and error prone.
I believe statements like the above can be made, and convincingly so,
without reference to personal experience.  Personal experience helps
illustrate the truth of such a statement, but the personal experience
can be distilled into a detailed rationale without having to describe
the actual personal experience.

I prefer dispassionate argument (though I admit that on occasion I
allow my passions to bleed into my arguments -- a personal failing).

Dispassionate argument, it seems to me, is best served by trying to
distill personal experience.  Dispassionate argument does not require
that one not present personal experience, of course, but I think it's
advisable to distill such experience as well, if not first.

> So, which bit of input would you expect to be more useful when making a
> decision about the documenet?

Neither.  I'd prefer:

    I believe the proposed design will not scale well for the
following reasons: <wisdom distilled from experience>.  [optional]
This comes from having observed similar failures in the field
<description of personal experience>.

Here the personal experience helps shed light on the rationale given,
but the rationale given ought to stand on its own.  Moreover, the
truth of such a statement might be obvious once the statement is made,
in which case the personal experience becomes irrelevant.  Moreover
still, if the truth of such a statement can easily be established, it
should not matter that the speaker has little or even no experience in
the field.

Put differently:  Argument by experience can be fallacious and/or
fraudulent at worst, often being just a point of view easily countered
by others' personal experience.  Then the degree to which the speaker
is a usual suspect or otherwise "important" becomes a key to giving
weight to their argument.  I don't think that would be a good thing,
particularly if we should *formalize* such a mode of argument (which
would make lambs of many participants, and wolfs of a few).

Nico
--

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 May 2011 10:32:24 -0700

On 5/12/2011 10:24 AM, Nico Williams wrote:
> On Thu, May 12, 2011 at 10:52 AM, Dave CROCKER<[email-masked]>  wrote:

> I prefer dispassionate argument

This isn't about passion (1st definition) but well might be about partiality 
from experience (2d/3rd definition).

Note that your own alternative example actually demonstrates that:

> following reasons:<wisdom distilled from experience>.  [optional]

How is the random reader to know that the speaker has that experience, unless it 
is declared.

Yes, it is better to state well-known or obvious facts.  ("This calls for a very 
large table but uses a linear search and that won't scale".)

However many interesting problems involve judgment about what will work. 
Experience of the speaker informs the likelihood that their opinion is well-founded.

> <description of personal experience>.

I'd class this as a useful version of what I was trying to describe.  Glad to 
see we agree...

d/
-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 12:47:03 -0500

> Note that your own alternative example actually demonstrates that:

Are you referring to dictionary definitions?  If so, which dictionary?
 As to my example, see below.

> How is the random reader to know that the speaker has that experience,
> unless it is declared.

I'm asserting that it is possible, at least sometimes (I gave a
real-world example from this very week, thus I have an existence
proof), to distill information from experience such that the
information stands alone.  I'm also asserting that whenever that is
possible, it's also preferable over stating experience as an
authority.  I'm also asserting that we might otherwise fall into a
habit of using the argument from authority fallacy as a mode of
argument.

> Yes, it is better to state well-known or obvious facts.  ("This calls for a
> very large table but uses a linear search and that won't scale".)
>

Indeed, and I don't argue that personal experience should be left out
of the speaker's statements.  I'm arguing that it shouldn't be
*required*, not even strongly recommended.  I believe the speaker will
figure out from others reactions when his statements are unconvincing
and when to reach for personal experience (in the hopes that others
will be better able to distill useful information from it, as opposed
to in the hopes of winning an argument from authority).

Moreover, I think this sub-thread is a bit of a waste of time.  It
seems quite contrary to the spirit of the IETF, and thus also risible,
that IETF LC participants should have to open their posts with any
sort of boilerplate designed to state their authority, or anything
remotely resembling the same.  I'm shocked that anything even
resembling such a thing is being proposed, and I hope I just horribly
misunderstood the actual proposal.

> I'd class this as a useful version of what I was trying to describe.  Glad
> to see we agree...

To the extent that I get a whiff of a proposal to require that
participants lead their arguments this way, I disagree, vehemently.
Otherwise we do agree, or at least fail to disagree (indeed, I might
not care enough to agree or not).

Can we get a clear statement as to what's being proposed?  If I
misread it, either I'm a poor reader or the proposal is not clear.

Nico
--

---

From: Joseph Yee <[email-masked]>
Date: Thu, 12 May 2011 22:30:10 -0400

[snip]

> misread it, either I'm a poor reader or the proposal is not clear.

Personal guess is ADs hope to see expanded review beyond "read and support", with reason of why we support.  I assume that no strict format at the beginning (try and evaluate first), otherwise we (as reviewers) might just provide a longer form of "read and support" statement.

Joseph

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 May 2011 00:14:17 -0500

> Personal guess is ADs hope to see expanded review beyond "read and support", with reason of why we support.  I assume that no strict format at the beginning (try and evaluate first), otherwise we (…

That's what I thought, and I agree with that.  Dave seemed to want to
go much further, but I wasn't sure whether a far-reaching proposal had
been made.