Consensus Call Tranche 1 (Document Organization)

Fri Oct 10 13:14:25 CEST 2008

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081010/c1b8774a/attachment-0001.htm 