[ietf-outcomes] Definitions and conflict process

[Dave CROCKER <[e-mail]>]

(opsarea mailing list dropped.)


David and Bernard, et al,


On 2/9/2010 12:28 PM, Bernard Aboba wrote:
> Dave Crocker said:
>
> "This means that a protocol is a failure if it is widely used, but for
> different purposes than it was intended."
>
> [BA] If a protocol has been implemented, deployed and used, I don't think
> that can qualify as a failure under the RFC 5218 definition. From Section
> 1.4:

You quote Section 1.4 and I quoted Section 1.2.  They appear to be conflicting 
definitions, and the conflict doesn't appear to be subtle.  Both bits of text 
are clearly written and easily understood.

So while it well might be good for us to have a single definition of 'success' 
that is universally applied, simply referring to the RFC does not seem to get us 
there.


> Dave Crocker also said:
>
> "Deployed" is also a problem, since there is a long track record of
> industry's having deployed something but never actually using it very much.
> I submit all of OSI as a prime example.

I'll repeat that I think we should have a trivial rule, and that I think it 
should simply be a measure of 'benefit'.  If people are using something, it has 
benefit.  If they have deployed it but are not using it, there is no benefit.

We need to be careful that we do not define an array of subtle distinctions that 
wind up adding to our effort but don't make major impact on the utility of the 
assessment exercise.

So, for example, the difference between deployment and use is not subtle, but 
just how much do we learn by adding the distinction to the core assessment 
effort?  Adding pieces to an assessment effort increases the complexity and the 
potential for disagreement.

Contrast this with:  The community agrees that a protocol is not used or is not 
used very much.  (A - or -- assessment.)  After we agree on that, folk ask what 
happened and discover that it was deployed but difficult to use.  That's worth 
knowing, but only /after agreeing that it wasn't used/.

In other words, the distinction between Used and Deployed is interesting as a 
derivative measure in the case of non-use, and is not interesting in the case of 
use.  That means it should not be part of the core assessment effort, which 
makes that effort simpler.



On 2/9/2010 10:34 AM, David Harrington wrote:
 > One problem with a wiki is that it can represent the personal opinion
 > of the last person to edit it, rather than to represent the consensus
 > of the IETF. But it is posted on the official IETF web site, and can
 > easily be mistaken to represent an official statement of consensus.

There are a few layers to dealing with this concern.  I fully expect that we 
will, indeed, eventually find conflict about an entry to be a serious problem. 
When we do, we'll have to proceed thoughtfully.

Stepping through the layers, here's my own, starting view:

The wiki software used by the IETF does not provide the wiki equivalent of email 
list 'moderation', where an authority can mandate certain controls on the text. 
  So the underlying mechanics of enforcing resolution of a conflict about an 
entry is going to have to rely on social conventions, rather than software 
mechanics.  If that becomes insufficient, we'll have to figure out some way to 
deal with it.

Although I did not write anything into the initial charter -- because I think 
there should be discussion and agreement before adding a statement about it -- I 
have assumed that the process for resolving conflicts about an entry should be 
debate and rough consensus on this mailing list.  I'm tasked with facilitating 
and assessing.

I'm a believer in overt steps to resolve debate, including on-list efforts to 
summarize and suggest compromises, and finally to make explicit, on-list 
statements about assessment of rough consensus.  Sometimes that can be reduced 
to a one-step "default yes", such as the change I just installed onto the wiki 
homepage and charter:  Bernard and I had a public exchange and quickly reached 
an agreement.  I waited a day and no one else chimed in.  Absent objections, I 
declared that I'd make the change, and then did.  To the extent that anyone 
comes in afterward and cares about this, they can see the sequence.  If they 
object and the group comes to consensus about wanting to reverse or modify the 
change, wiki's make this easy.

If there is a disagreement about my handling of any wiki or mailing list issues, 
I'm assuming we can invoke the usual appeals process, through the IESG. 
(Authorization for establishing the wiki on the IETF site came from the IETF 
Chair, so I assume that's the reporting structure for on-going issues.)

It is certain that there are issues about changing the wiki's format or contents 
that will run into a problem that requires new or different procedures.  As 
these come up, we will figure them out, as long as the community stays engaged 
in the effort.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net