Consensus Call Tranche 1 (Document Organization)

Fri Oct 10 14:28:22 CEST 2008

In some working groups, to avoid this problem (be it real or not --
although the "problem" can be discussions of this type), the chairs have
adopted a policy to _require_ positive confirmation before declaring
consensus.  The idea is that if chairs can't get at least a few working
group members to state support for something, there is likely a bigger
problem.

I think it is a good policy.  Possibly it could be discussed in some
IETF policy document, if that is not already the case.

/Simon

Vint Cerf <vint at google.com> writes:

> Martin,
>
> thanks for these comments.
>
> with regard to the effort to assess consensus, if a lone voice spoke
> against and there was silence otherwise, I would think we'd
> reasonably conclude that we could move forward on the assumption that
> those silent were in agreement. The reason I think one needs to take
> that view is that otherwise a single dissenter could prevent any
> forward progress. By the same token, if many speak in favor and few
> against, it might be reasonable to take this as indication of rough
> consensus. One problem with working via mailing lists is that the
> expressions are often somewhat lopsided insofar as those who disagree
> are more likely to express themselves than those in agreement. Hence
> an effort to encourage both views to be expressed and also to assume
> that no response is an indication of agreement.
>
> For a practical case, the first tranche proposing to adopt the
> rationale document as it was presented, does not appear to have rough
> consensus  (at the end of this day, we will have "final" data for
> this round of expression).
>
> vint
>
>
>
> NOTE NEW BUSINESS ADDRESS AND PHONE
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
> On Oct 10, 2008, at 4:01 AM, Martin Duerst wrote:
>
>> At 05:54 08/10/07, Vint Cerf wrote:
>>> DUE DATE: October 10, 2008 (ET)
>>>
>>> Place your reply here:
>>
>> NO.
>>
>> Rationale:
>> - While John has shown in -03 that there are some differences
>>   between him and Mark in terms of what should be normative and
>>   what not, I don't think these will take that long to hash out
>>   (as far as I have checked, I lean somewhat more towards John's
>>   assessment than Mark's, but still somewhat in between).
>>
>> - The parts of the Rationale document that I have read give me
>>   the impression that it's far from ready, for ANY purpose.
>>   The main problems are:
>>   1) It's written in present or future tense, like "here's
>>      what we are going to do, and why", in many places,
>>      which means it has to be re-written to actually be
>>      readable after publication. While such a rewrite might
>>      slightly lower its value for current readers, the
>>      earlier this is done, the better.
>>   2) While the document makes several successful attempts
>>      at clarifying some of the rationale behind some of
>>      the design and some of the changes between 2003 and 2008,
>>      each of the pieces is written with some assumptions about
>>      previous knowledge, and these assumptions differ widely,
>>      and aren't built up step by step or made explicit.
>>      I would personally not recommend anybody to read this
>>      document unless I'd be sure the person is so much into
>>      IDNA and related issues already that s/he can take a
>>      critical approach to the document (being able to
>>      identify its strengths and weaknesses) or I'd be sure
>>      I'd be able to babysit the reader to correct wrong
>>      assumptions.
>>
>> - I'm not exactly happy with the way this "consenus call" is
>>   carried out. While I don't think there is something "deeply"
>>   flawed, I don't think that "in the absence of a consensus against
>>   each proposal, it will be assumed that the proposal is acceptable
>>   to the Working Group." agrees with IETF practice. IETF practice
>>   uses rough consensus to move forward, it doesn't redefine
>>   no consensus as consensus for whatever is currently around.
>>
>>
>> Regards,   Martin.
>>
>>
>>> COMMENTS:
>>>
>>>
>>> Procedure:
>>>
>>>
>>> There are several decisions that the working group will need to
>>> make to confirm consensus.  I will send a series of proposals over
>>> the next two weeks requesting YES or NO positions on each within a
>>> 4 day window. If NO is the response, a reason for that position
>>> needs to be stated. If there is a clear consensus based on
>>> responses or in the absence ofa consensus against each proposal,
>>> it will be assumed that the proposal is acceptable to the Working
>>> Group.
>>>
>>>
>>> Parenthesized symbols (e.g., "(R.1)") after the items are
>>> references to the issues lists where additional explanations can
>>> be found, as sent by John Klensin as body parts "idnabis-protocol- 
>>> issues-rev3" and "idnabis-rationale-issues-03" on a message titled
>>> Issues lists and the "preprocessing" topic'  to the working group
>>> on 18 August (<http://www.alvestrand.no/pipermail/idna-update/2008- 
>>> August/002537.html>http://www.alvestrand.no/pipermail/idna-update/
>>> 2008-August/002537.html)
>>>
>>> This group needs to get its documents out; it is behind its
>>> original schedule. It should be noted that the IDN ccTLD and gTLD
>>> selection initiatives at ICANN have already begun so that delay
>>> may weaken the IETF's ability to assist in a rational deployment
>>> of IDNA.
>>>
>>>
>>> (1) Document organization
>>>
>>>
>>> (1.a) The Rationale document should be retained to support
>>> implementors whose work requires that they understand the
>>> reasoning behind certain design choices.  The philosophy of
>>> IDNA2008 relies strongly on the ability of registries (especially
>>> those of top-level domains) to properly constrain the choice of
>>> labels even if they are composed of characters that are protocol
>>> valid.  (R.1)
>>>
>>> (1.b) While there has been debate about whether or not the content
>>> of the Rationale document should contain normative material, it
>>> seems expedient to agree on the content of Rationale for Proposed
>>> Standard without attempting to separate it into multiple parts.
>>> Therefore, it appears that the WG consensus is that: The normative
>>> material (definitions) should be retained in Rationale.
>>>
>>> A YES means you concur with the consensus statements above.
>>>
>>> The alternative is:
>>>
>>> - The normative material should be removed from Rationale and
>>> extracted to a separate document (for example Terms and Concepts)
>>> even if this lengthens the WG's target dates for an unknown period
>>> of time.  Note that there may be controversy about what material
>>> is normative and what is not; that is a separate consensus issue
>>> and may also take an unknown period of time to resolve   (R.2)
>>>
>>>
>>> NOTE NEW BUSINESS ADDRESS AND PHONE
>>> Vint Cerf
>>> Google
>>> 1818 Library Street, Suite 400
>>> Reston, VA 20190
>>> 202-370-5637
>>> <mailto:vint at google.com>vint at google.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>>
>> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>> #-#-#  http://www.sw.it.aoyama.ac.jp
>> mailto:duerst at it.aoyama.ac.jp
>>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update