Return-Path: Received: from eikenes.alvestrand.no ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.1.11-Mandrake-RPM-2.1.11-1mdk) with LMTP; Tue, 11 Jan 2005 12:37:08 +0100 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFF7F61BAF for ; Tue, 11 Jan 2005 12:37:08 +0100 (CET) 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 14869-06 for ; Tue, 11 Jan 2005 12:37:07 +0100 (CET) Received: from people.com.cn (unknown [202.99.23.227]) by eikenes.alvestrand.no (Postfix) with SMTP id B036761B91 for ; Tue, 11 Jan 2005 12:37:05 +0100 (CET) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm441e42d29; Tue, 11 Jan 2005 19:37:02 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd41defc6f; Sat, 08 Jan 2005 01:36:42 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm341df34aa; Sat, 08 Jan 2005 01:36:38 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 08 Jan 2005 01:36:38 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmxvs-0002QN-HE; Fri, 07 Jan 2005 12:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxnI-0007dj-9r for ietf@megatron.ietf.org; Fri, 07 Jan 2005 12:21:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29173 for ; Fri, 7 Jan 2005 12:20:57 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmy09-0007gz-UR for ietf@ietf.org; Fri, 07 Jan 2005 12:34:28 -0500 Received: from lns-p19-19-idf-82-249-7-129.adsl.proxad.net ([82.249.7.129] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.43) id 1Cmxn4-00031k-1S; Fri, 07 Jan 2005 09:20:47 -0800 Message-Id: <6.1.2.0.2.20050107172246.047f0cb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 07 Jan 2005 18:20:42 +0100 To: Harald Tveit Alvestrand , Dave Crocker , ietf@ietf.org From: "JFC (Jefsey) Morfin" In-Reply-To: References: <200516104826.996163@bbprime> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-40C4E61 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: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: Re: individual submission Last Call -- default yes/no. 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-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: jefsey@jefsey.com X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Virus-Scanned: by amavisd-new at alvestrand.no Harald, This does not discuss the language tags comment. This case however provides some experience. The real problem I see is the increased need of Practice Documentation. RFC 3066 is a BCP yet it introduces issues (and the proposed RFC 3066bis does more) which are not established but proposed or even modified practices, without the proper debate with other areas some consider as concerned (IDN, OPES, Web Services, architecture, etc.) what an IAB approved charter would have warranted. In this case there is also the oddity of a private list bearing responsibilities on the IANA. You say this may happen when the matter has not been considered being worth a WG. I have nothing to object to that. But I can document that in this particular case I sent you a private mail a few months ago asking guidance on the way to organize a WG. You did not signaled me your "ietf" list. I can also only note this is a consistent position with the IAB/IESG, since RFC 3869 does not even allude to the matter. That some's positions are more equal than other is a feature of 1st generation networks, so I will not object. But I suggest this calls for a better WG proposition track. In this case a WG would have saved time and harassment (I am used to be insulted and I have no problem with it, should it help). IRT the need of PB documentation. This case shows that there would have been no problem and full consensus if the "BEST" as documented in RFC 2026.5.1 could have been replaced by a "DOCUMENTED" or by a "SUGGESTED". This made me a supposed "main" and "odious" and "gerrymandering" etc... "opponent" of the draft. Should the author have been able to present a DCP for what is already in use, and an SCP for what he proposes, we would now considered how to continue further, may be along the working protocol I documented. I can quote many other areas where such a SCP/DCP use could lead to a progressive practice aggregation or transition and innovation. Regards. jfc At 10:46 07/01/2005, Harald Tveit Alvestrand wrote: >[note - this note does NOT talk about the language tags document] >Recent standards-track/BCP RFCs that came in as individual submisssions >(you can tell this from the draft name in the rfc-editor.xml file): > >RFC 3936 - draft-kompella-rsvp-change >RFC 3935 - draft-alvestrand-ietf-mission >RFC 3934 - draft-wasserman-rfc2418-ml-update >RFC 3915 - draft-hollenbeck-epp-rgp >RFC 3912 - draft-daigle-rfc954bis > >Apart from draft-alvestrand, I don't remember any of these causing much of >a stir at Last Call. Still, I think the decision to advance them was >appropriate. >The usual case for an individual submission is, I think: > >- there are a number of people who see a need for it >- there are a (usually far lower) number of people who are willing to work >on it >- someone thinks that this isn't controversial enough for a WG, isn't work >enough that the extra effort of setting up a WG is worth it, is too >urgently needed to wait for a WG to get up to speed, or other version of >"doesn't fit with our WG process >- nobody's significantly opposed to getting the work done > >A "default no" doesn't seem like a correct procedure here. > > Harald > > > >--On 6. januar 2005 10:48 -0800 Dave Crocker wrote: > >>> However the reason >>> why many things come in as individual submissions is that the community >>> doesn't care much. >> >>I sure hope you are very, very wrong. >> >>If the community does not care much, then I do not see the purpose in >>making it an IETF standard. >> >>A standards process is primarily about gaining community support for a >>common way of doing something. >> >> >>So if the IESG is satisfied enough to put out a last >>> call, and nobody responds -- it doesn't have community support -- the >>> default community position shouldn't be "no" but "no objection". >> >>That's a default 'yes'. >> >>We already have a problem with producing specifications that no one uses. >>A default 'yes' on outside submissions makes it likely we will get lots >>more. >> >> >> >>d/ >>-- >>Dave Crocker >>Brandenburg InternetWorking >>+1.408.246.8253 >>dcrocker a t ... >>WE'VE MOVED to: www.bbiw.net >> >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf > > > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf