Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP)

r&d afrac <rd@afrac.org> Mon, 29 August 2005 11:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9i0w-0001A0-ES; Mon, 29 Aug 2005 07:41:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dqP-0006Xe-8b; Mon, 29 Aug 2005 03:14:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20926; Mon, 29 Aug 2005 03:14:11 -0400 (EDT)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9drg-0005Lm-2g; Mon, 29 Aug 2005 03:15:33 -0400
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E9dqM-00023y-5z; Mon, 29 Aug 2005 00:14:10 -0700
Message-Id: <6.2.3.4.2.20050829090011.04dcc7f0@mail.afrac.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 29 Aug 2005 09:07:45 +0200
To: Doug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
In-Reply-To: <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL>
References: <20050829052419.JNUF6870.mta1.adelphia.net@megatron.ietf.org> <01d101c5ac5c$986ee3e0$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - afrac.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
X-Mailman-Approved-At: Mon, 29 Aug 2005 07:41:11 -0400
Cc: ietf@ietf.org, iesg@iesg.org
Subject: Re: [Ltru] Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 07:43 29/08/2005, Doug Ewell wrote:
>r&d afrac <rd at afrac dot org> wrote:
>
> > - I supported the proposition of an African searcher (they treated of
> > troll) to reconcile the desire of a strict ABNF expressed by the WG
> > affinity group and the users, R&D and innovation (following ISO
> > evolution) support to use the URI-tags RFC in proposing first to use
> > the "private use" area. As indicated, a remark shown me it was a
> > wrong choice, the private use area also addressing other needs.
>
>Merriam-Webster OnLine defines "affinity group" as "a group of people
>having a common interest or goal or acting together for a specific
>purpose (as for a chartered tour)."
>
>Exercise for the reader:  Explain why this is a bad thing for an IETF
>Working Group.

Slowly, the good questions are asked. May be can I suggest to read:

"RFC 3774 2.2.6: Members of this affinity group tend to talk more 
freely to each other and former members of the affinity group - this 
may be because the affinity group has also come to share a cultural 
outlook which matches the dominant cultural ethos of the IETF (North 
American,  English speaking).  Newcomers to the organization and 
others outside the affinity group are reluctant to challenge the 
apparent authority of the extended affinity group during debates and 
consequently influence remains concentrated in a relatively small 
group of people.

This reluctance may also be exacerbated if participants come from a 
different cultural background than the dominant one."

Obviously I am not much impressed by such "apparent authority" 
....  But the affinity group can use its number of to make believe 
and organise consensus by exhaustion:

"RFC 3774 2.7: On the other hand, the decision making process must 
allow discussions to be re-opened if significant new information 
comes to light or additional experience is gained which appears to 
justify alternative conclusions for a closed issue. One cause that 
can lead to legitimate attempts to re-open an apparently closed issue 
is the occurrence of 'consensus by exhaustion'. "

Take care.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf