Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Fri, 26 Aug 2005 14:59:14 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 747E0320091 for ; Fri, 26 Aug 2005 14:59:14 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16012-01 for ; Fri, 26 Aug 2005 14:59:09 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80CBE32008E for ; Fri, 26 Aug 2005 14:59:03 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dn4-0006be-T3; Fri, 26 Aug 2005 08:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dn1-0006bZ-O5 for ietf@megatron.ietf.org; Fri, 26 Aug 2005 08:58:35 -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 IAA17463 for ; Fri, 26 Aug 2005 08:58:34 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8dnk-0005Yl-43 for ietf@ietf.org; Fri, 26 Aug 2005 08:59:21 -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 1E8dmq-0000xL-94; Fri, 26 Aug 2005 05:58:24 -0700 Message-Id: <6.2.3.4.2.20050826142135.049e1a60@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 26 Aug 2005 14:58:20 +0200 To: Brian E Carpenter From: "JFC (Jefsey) Morfin" In-Reply-To: <430EF843.3000709@zurich.ibm.com> References: <6.2.3.4.2.20050826005941.03dcdeb0@mail.jefsey.com> <430EF843.3000709@zurich.ibm.com> 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 - jefsey.com X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ietf@ietf.org Subject: Re: IESG powers - was: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no At 13:08 26/08/2005, Brian E Carpenter wrote: >JFC (Jefsey) Morfin wrote: >>just a remark here. In the RFC 3066bis Last Call case the IETF has >>the capacity not only to "police" but to "impose" and "force". This >>is the case when a memo documents a IANA registry. In the case of a >>standard track memo, there can be an appeal before it is imposed. >>It seems not in the case of a BCP. > >Wrong. IESG approvals of a standards track draft or of a BCP are equally >subject to appeal within two months. Dear Brian, I do not say that BCP are not subject to appeal, but that in the case of a standard track an appeal delays the enforcement and that in the case of BCP it does not. My sources are quoted below. Entries have been made _months_ago_ on East Asian languages in the _current_ registry in using the Draft registry format, however initially opposed by the reviewer. Should the Draft be accepted, the registry update will be requested immediately and products will ship on the faith of the accepted drafts. This will impose the Draft through usage, rising objections to a "change" resulting from an appeal. If you warranty that this is not the case and that this Draft can only be result in a reload of the IANA registry after the appeals (IESG and possibly IAB) are exhausted, this will help everyone getting more serene as the complexity of the issue calls for. This will permit more Members of the IETF community to become familiar with the architectural aspects at stake, and to people from the cultural world and from more languages to assess the involved issues. My "Draft as a default, not as an exclusive" proposition gives that time, but over the years to come and without delaying the deployment. Should it be refused, appeals would block the implementation for a few months. This would be the only delay left to avoid balkanisation and an e-cultural world war. Experience from French/European cultural exception policy, European response to Google scannerisation project, Chinese Names, UNESCO positions and funding for a multilingual Cyberspace, NICSO equal linguistic opportunity declaration, MINC positions, Eurolinc's Louis Pouzin WSIS contributions, WGIG multilingual priorities, etc. show that - even if most of the IETF Members are unaware - this technical, political and societal issue, is not only commercial. jfc At 18:50 24/08/2005, Harald Tveit Alvestrand wrote: >--On 24. august 2005 12:19 -0400 "John.Cowan" > wrote: >A process question: does a BCP go into effect when it is passed for >>publication as an RFC, or when it is actually published as an RFC, >>months or years later? > >When it is passed (see tradition with BCP 101). Setting up the >administrative details to actually act like the BCP says can take a >little time, of course. >Harald At 20:20 24/08/2005, Randy Presuhn wrote: > > From: "Frank Ellermann" > > On average four months, not years. For an RfC the "effect" > > (as far as IANA is concerned) is apparently very fast, one > > experimental RfC approved less than two months ago with two > > IANA "effects" is ready for at least three weeks now, IIRC. >... >Before a document is even approved for hand-off to the RFC editor, >IANA will take a look at in in conjunction with the IESG review. In my >experience, they go through the IANA considerations sections *very* >carefully, and are not shy about asking questions or requesting clarification. >Consequently, by the time the RFC appears, IANA has already known >for some time what would need to be done to implement a registry, >so it should not come as a surprise that they are able to activate them >quickly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf