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; Fri, 07 Jan 2005 18:20:51 +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 D877861C13 for ; Fri, 7 Jan 2005 18:20:51 +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 07819-01 for ; Fri, 7 Jan 2005 18:20:49 +0100 (CET) Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id E922A61B8D for ; Fri, 7 Jan 2005 18:20:48 +0100 (CET) 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" Subject: Re: individual submission Last Call -- default yes/no. 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 - alvestrand.no 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: 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 >