Re: [iucg] RFC 5890 on Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework

JFC Morfin <jefsey@jefsey.com> Wed, 18 August 2010 17:17 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: iucg@core3.amsl.com
Delivered-To: iucg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384913A699C for <iucg@core3.amsl.com>; Wed, 18 Aug 2010 10:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.442
X-Spam-Level:
X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[AWL=1.557, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n99GEga9zEAO for <iucg@core3.amsl.com>; Wed, 18 Aug 2010 10:17:53 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 84EFD3A67FE for <iucg@ietf.org>; Wed, 18 Aug 2010 10:17:53 -0700 (PDT)
Received: from 119.187-227-89.dsl.completel.net ([89.227.187.119]:57884 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1OlmHN-0005B7-OO; Wed, 18 Aug 2010 10:18:22 -0700
Message-Id: <7.0.1.0.2.20100818094628.05ba4cf0@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 18 Aug 2010 19:18:32 +0200
To: "olaf M. Kolkman" <olaf@NLnetLabs.nl>, Russ Housley <housley@vigilsec.com>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <7B88C6AD-4660-4E8D-ACD3-2A5472A66A2D@riveronce.com>
References: <20100804153719.16662E06B1@rfc-editor.org> <7.0.1.0.2.20100804205235.0574ccf0@jefsey.com> <7B88C6AD-4660-4E8D-ACD3-2A5472A66A2D@riveronce.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 - montage2.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-Source:
X-Source-Args:
X-Source-Dir:
Cc: Glenn Kowack <glenn@riveronce.com>, workon@idna2010.org, iucg@ietf.org, rfc-editor@rfc-editor.org
Subject: Re: [iucg] RFC 5890 on Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2010 17:17:55 -0000

Dear Chairs,

Since:

* it appears that there is a non-published (AFAIK) change in the 
Editor's rules which possibly lead me to a partly inappropriate 
timing and wrong conclusions about the IDNA2008 expedited publication.

* this change deeply affects the entire Internet standardization and 
appeal process as I understood it, and affects the procedure of my 
ongoing appeal.

* the very matter of the appeal is the IAB/IESG procedure being used 
in publishing the IDNA2008 documentation set, I find possibly more detrimental.

* there are possible conflicts of interest between different 
strategies documented by the participants in the IDNA2008 and appeal process.

* with consequences:

*** for the information of the IETF, the Internet Users, and the 
entire Internet community on the architectural extensions illustrated 
(hence introduced) by IDNA2008
*** for the business and legal strategy of IDNgTLDs candidates and, 
in this way, on the future of the whole Internet governance
*** for where and by who should be documented and experimented on 
concerning the IDNA2008 consequences with an impact on the IETF Trust 
properties related to my Free Architecture (ALFA) 
(http://wikalfa.org) so, for the time being at least, it may stay in 
public domain.

* the target of my appeal is not to repel RFC 5890, 91, 92, 93, and 
94 but is rather clearly explained as the attempt to ensure that no 
one can complain that I have not carried out everything possible to 
ensure that IESG and IAB could document how they wanted me to 
introduce what I supported in the IDNA2008 consensus in terms of 
Internet architecture extension, and its consequences.

Glenn's response must be documented by the IESG ("corresponding 
stream"), and "IAB" and must appear in some appeal responses. Should 
I, therefore, file a second appeal or could this mail and a comment 
by the IESG be attached to my ongoing appeal, so that the IAB could 
include its own response in their main pending response to my appeal?

I thank you for your response.

jfc

At 03:00 18/08/2010, Glenn Kowack wrote:
>Dear Jefsey,
>regarding matters of publication of RFCs, the RFC Editor takes 
>direction from the corresponding stream and the IAB.  Please direct 
>your correspondence to these parties.
>
>sincerely yours,
>Glenn Kowack
>Transitional RFC Series Editor
>
>___
>
>
>On Aug 4, 2010, at 3:42 PM, jefsey wrote:
>
> > Dear Editor,
> >
> > this seems to me in contradiction with Editor rules and/or 
> practices to publish document of which the publication under 
> appeal. Except if you have been demanded by IAB or IETF/IESG Chair, 
> or if IAB has answered my appeal but has not published it yet? 
> Otherwise, my reading is that this publication is premature and due 
> to what depends on the IAB response, possibly causes unnecesary 
> harm to the Internet, what your role is in such a case - as far as 
> I understand the RFC - to prevent.
> >
> > Please refer to the statements of Joyce Reynold of the similar 
> case of RFC 4647, except that IESG and RFC-Editor played by the rules.
> > Best
> > jfc
> >
> > At 17:37 04/08/2010, rfc-editor@rfc-editor.org wrote:
> >
> >> A new Request for Comments is now available in online RFC libraries.
> >>
> >>        RFC 5890
> >>
> >>        Title:      Internationalized Domain Names for Applications
> >>                    (IDNA): Definitions and Document Framework
> >>        Author:     J. Klensin
> >>        Status:     Standards Track
> >>        Stream:     IETF
> >>        Date:       August 2010
> >>        Mailbox:    john+ietf@jck.com
> >>        Pages:      23
> >>        Characters: 54245
> >>        Obsoletes:  RFC3490
> >>
> >>        I-D Tag:    draft-ietf-idnabis-defs-13.txt
> >>
> >>        URL:        http://www.rfc-editor.org/rfc/rfc5890.txt
> >>
> >> This document is one of a collection that, together, describe the
> >> protocol and usage context for a revision of Internationalized Domain
> >> Names for Applications (IDNA), superseding the earlier version.  It
> >> describes the document collection and provides definitions and other
> >> material that are common to the set.  [STANDARDS TRACK]
> >>
> >> This document is a product of the Internationalized Domain Names 
> in Applications (Revised) Working Group of the IETF.
> >>
> >> This is now a Proposed Standard Protocol.
> >>
> >> STANDARDS TRACK: This document specifies an Internet standards track
> >> protocol for the Internet community,and requests discussion and 
> suggestions
> >> for improvements.  Please refer to the current edition of the Internet
> >> Official Protocol Standards (STD 1) for the standardization state and
> >> status of this protocol.  Distribution of this memo is unlimited.
> >>
> >> This announcement is sent to the IETF-Announce and rfc-dist lists.
> >> To subscribe or unsubscribe, see
> >>  http://www.ietf.org/mailman/listinfo/ietf-announce
> >>  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> >>
> >> For searching the RFC series, see 
> http://www.rfc-editor.org/rfcsearch.html.
> >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> >>
> >> Requests for special distribution should be addressed to either the
> >> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> >> specifically noted otherwise on the RFC itself, all RFCs are for
> >> unlimited distribution.
> >>
> >> The RFC Editor Team
> >> Association Management Solutions, LLC
> >
> > At 21:50 14/08/2006, Joyce Reynolds wrote:
> >> Jefsey,
> >>
> >> 1)  Expedited process of documents for RFC publication is not encouraged
> >> for the reason you mentioned: "...one cannot expedite one particular
> >> RFC publishing process, by-passing and delaying all the others."
> >> However, if the IESG feels there is a just cause to expedite a
> >> document, the IESG must approve the request and inform the RFC Editor
> >> to expedite.
> >>
> >> 2)  If a document has been approved by the IESG for publication, and an
> >> appeal has been logged against the document, the RFC Editor places the
> >> document in "IESG" state, pending resolution of the appeal.  When the
> >> appeal via the IAB has been resolved, the RFC Editor will take
> >> direction from the IETF chair to publish.
> >>
> >> Joyce
> >> (for the RFC Editor)
> >
> >
> > At 00:07 15/08/2006, JFC Morfin wrote:
> >> Dear Joyce,
> >> I thank you for your response.
> >> jfc
> >
> > At 01:18 17/08/2006, JFC Morfin wrote:
> >> Dear Joyce,
> >> for your information I forwarded my appeal 
> (http://jefsey.com/appeal-matching-iesg.pdf) to the IESG. There are 
> many technical and strategic issues, two points are I think more practical:
> >>
> >> - I appeal the idea to expedite publication because (a) this a 
> BCP and that status was obtained to get the document as 
> authoritative from the IESG approval (b) they should be quoted as 
> BCP 47 as they are subject to new changes (c) the Unicode need is 
> related to a Conference where the autors are presenters and are 
> concerned by their personal image.
> >>
> >> - the BCP 47 as it is, has the concept of "primary languages" 
> when compared to "extended languages" within the same ISO 639-3 
> language list. The "matching draft" is to help filtering users. 
> This has racists connotations, which are injurious to the extended 
> languages locutors and should be corrected before publication. The 
> IETF and the RFC do not need that kind of image!
> >>
> >> Thank you for all the work you did and keep doing.
> >> jfc
> >
> > At 23:01 22/08/2006, Joyce Reynolds wrote:
> >> Jefsey,
> >> The RFC Editor has received your email.
> >> Joyce
> >
> > At 17:38 31/08/2006, Joyce Reynolds wrote:
> >> Jefsey,
> >> It was formally requested by the IETF/IESG Chair (on behalf of the
> >> IESG) to continue with expedited publication of
> >> draft-ietf-ltru-matching-15.
> >> So, we have continued on with the publication.
> >> Best regards, Joyce
> >> (for the RFC Editor)
> >
> > At 23:59 31/08/2006, Joyce Reynolds wrote:
> >> Jefsey,
> >> You may do either.  Send a note to the IAB, or to the IETF/IESG Chair
> >> and the IAB Chair.
> >>
> >> Regards, Joyce
> >> (for the RFC Editor)
> >
> >
> > Jefsey wrote:
> >> Dear Joyce,
> >> this is very embarassing.
> >>
> >> - you told me that if a document was under appeal you put it on hold
> >> until IAB decision. This seems to be a policy you adopted with IAB
> >> approval as you published it. This also seems in line with RFC 2850
> >> ("The IAB must approve the appointment of an organization to act as
> >> RFC Editor and the general policy followed by the RFC Editor.") and
> >> RFC 2026 ("RFC publication is the direct responsibility of the RFC
> >> Editor, under the general direction of the IAB.").
> >>
> >> - my understanding is that you are the one to technically decide when
> >> something is harmful for the internet and the internet community.
> >> This is my reading of RFC 3932 ("The new review model will have the
> >> IESG take responsibility ONLY for checking for conflicts between the
> >> work of the IETF and the documents submitted; soliciting technical
> >> review is deemed to be the responsibility of the RFC Editor." and "if
> >> the  the IESG has not found any conflict between a submission and
> >> IETF work, then judging its technical merits, including
> >> considerations of possible harm to the Internet, will become the
> >> responsibility of the RFC Editor.  The IESG assumes that the RFC
> >> Editor, in agreement with the IAB, will manage mechanisms for
> >> additional technical review.")
> >>
> >> The problem for me is that:
> >> - IMHO the proposed drafts are harmful for the internet (technically
> >> wise) and to the internet community.
> >> - the IESG has not "not found any conflict" as it has accepted my
> >> appeal and does consider it.
> >> - the IESG has published a rechartering to at least obsolete 
> that documents.
> >> - the standard process allows me to comment on this new Charter and
> >> possibly to appeal against it, while the problem is not a lack of
> >> competence of the WG but a lack of IAB guidance of the WG not to
> >> biase the IETF in favor of an exclusive technology and create a layer
> >> violation which opposes the ISO documents and doctrine it is supposed
> >> to adapt to the Internet environment.
> >>
> >> We are in a case where You have indicated that you wanted to keep the
> >> document on hold until the end of the IAB review, what seems to be in
> >> agreement with the fact that the IESG assumes that you will consider
> >> the additional technical review with the IAB.
> >>
> >> I suppose this is to be refered to the IAB. I also suppose that if
> >> you were formally requested by the IETF/IESG Chair on behalf of the
> >> IESG to expedite the publication of a document in spite of an appeal
> >> to the IAB against considering such an expedition, and an appeal to
> >> the IESG against the publication of this document as harmful to the
> >> internet technology and community, I have no problem in quoting your
> >> mail to the IAB? Or do you prefer that I send a mail to the IETF/IESG
> >> Chair and IAB Chair asking why the document is in AUTH48?
> >
> > At 23:59 31/08/2006, Joyce Reynolds wrote:
> >> Jefsey,
> >> You may do either.  Send a note to the IAB, or to the IETF/IESG Chair
> >> and the IAB Chair.
> >>
> >> Regards, Joyce
> >> (for the RFC Editor)