From david.sinicrope@ericsson.com Thu Mar 21 12:31:58 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975A521F905C; Thu, 21 Mar 2013 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZSzIBLynJAQ; Thu, 21 Mar 2013 12:31:57 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B038B21F8CA4; Thu, 21 Mar 2013 12:31:57 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-f8-514b602c0946 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 27.10.02411.C206B415; Thu, 21 Mar 2013 20:31:57 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 15:31:56 -0400 From: David Sinicrope To: "Andrew G. Malis" Thread-Topic: [Tools-discuss] Request for IETF WG and BOF Session Minutes Thread-Index: AQHOJhikeKzPaSH650C2NG3O3pPxK5iwKduAgABfcho= Date: Thu, 21 Mar 2013 19:31:55 +0000 Message-ID: References: <8D23D4052ABE7A4490E77B1A012B630775117B16@mbx-01.win.nominum.com> <514AC623.2080706@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C1274F318AAD4D2D8951C0C8354CF3F5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPlK5ugnegwedGLot7V5exW2x9v4/N ou3iPiaL7UfmMlr83z+F0YHVY+esu+weS5b8ZApgiuKySUnNySxLLdK3S+DKWDKnl72gz7zi zp5TrA2Ms3W7GDk5JARMJB6vbmKHsMUkLtxbz9bFyMUhJHCEUWLujomsEM5yRonmXT2MIFVs QB3rNu5hAbFFBDQkFnw8zwRSxCywiVHi7Ov1rCAJYQEPie4nvWwQRZ4SM+a/YoawrSRmTt4P 1swioCqx6dE2MJtXwF5i7s5DLBDbTjNJzJ2yEmwQp0CgxMWLi8EGMQLd9/3UGiYQm1lAXOLW k/lMEHcLSCzZc54ZwhaVePn4HytETbJEw8dWqAWCEidnPmGZwCgyC0n7LCRls5CUQcR1JBbs /sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFqWW56UaGmxiBEXZMgs1xB+OCT5aHGKU5WJTE eUNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCyK2eX3tKpDjPVlW+7WiDbRiH9mBe+i rvN83x6zh91sx002Dr51qW3PAg0YTmjFZDtk/NLz8atcuvFeyEnNFDO762+TAx5vq3d8eNN5 x/svke3G24QLwqKV+86s2qiy9rnr0pkLRZgO8v4vfyIif8VB11DQ7vh1xoavvxIE1Vas63ib sb42RYmlOCPRUIu5qDgRAJP5B8B+AgAA X-Mailman-Approved-At: Fri, 05 Apr 2013 02:35:41 -0700 Cc: "" , Brian E Carpenter , Tools discussion Subject: Re: [Tools-discuss] Request for IETF WG and BOF Session Minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:31:58 -0000 --_000_C1274F318AAD4D2D8951C0C8354CF3F5ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aw shucks, it ain't nothin'. Seriously, thanks for the kind words but it doesn't need to be that much wo= rk. I usually: - Ask for time, topic, name, draft URL, and presentation objectives in the = slot call email - make the agenda from cut and paste of the info received and format as the= template for the minutes. - take notes into the agenda file and save as the minutes. Don't try to cap= ture each word or slide points but rather summarize key verbal points and d= ecisions made on the mikes. - keep jabber open to catch names and missed points at the mikes (Thanks Ya= akov) - save often - spend 5 min to clean up the notes and post a draft version before leaving= the room so it doesn't get forgotten. It's not always pretty but sufficient. Dave On Mar 21, 2013, at 10:50 AM, "Andrew G. Malis" > wrote: My WG is lucky to have a WG secretary who prepares the agenda and takes the= minutes. Having a stable minute-taker goes a long way to getting them done= in a timely and consistent manner. I encourage other WG chairs to seek out= secretaries for their WGs. Asking a colleague in your own organization can= be an easy way to start. Cheers, Andy On Thu, Mar 21, 2013 at 10:43 AM, Bob Hinden > wrote: On Mar 21, 2013, at 9:34 AM, Brian E Carpenter wrote: > On 20/03/2013 20:23, Ted Lemon wrote: >> On Mar 20, 2013, at 2:44 PM, Marc Blanchet > wrote: >>> 1) at the end of each meeting, if the wg etherpad contains more than 50= 0 characters, then it is considered potential minutes. >>> 2) after one week, an automated tool takes this etherpad and put it int= o meeting materials as wg minutes and send an email to the wg chairs and wg= mailing list saying what it did. >>> 3) wg chairs can always push another version, since they will have an o= pportunity. >>> 4) at the cutoff for proceedings, they become official minutes. >> >> This seems like it would produce more bad results than good results > > Definitely. A rough transcript is not the same things as minutes. > Minutes are supposed to be a comprehensible summary of points made > and conclusions reached. There is no easy way to produce good minutes; > it's hard work. That's my view as well. We have the jabber logs for a rough transcript of = the meeting. If the chairs of a working group consistently don't produce minutes by the = deadline, then the ADs should get new w.g. chairs. Bob --_000_C1274F318AAD4D2D8951C0C8354CF3F5ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<blush>
Aw shucks, it ain't nothin'.

Seriously, thanks for the kind words but it doesn't need to be that mu= ch work.
I usually:
- Ask for time, topic, name, draft URL, and presentation objectives in= the slot call email
- make the agenda fr= om cut and paste of the info received and format as the template for the minutes. 
- take notes into the agenda file and save as the minutes. Don't try t= o capture each word or slide points but rather summarize key verbal points = and decisions made on the mikes.
- keep jabber open to catch names and missed points at the mikes (Than= ks Yaakov)
- save often
- spend 5 min to clean up the notes and post a draft version before le= aving the room so it doesn't get forgotten. 

It's not always pretty but sufficient.
Dave









On Mar 21, 2013, at 10:50 AM, "Andrew G. Malis" <amalis@gmail.com> wrote:

My WG is lucky to have a WG secretary who prepares the age= nda and takes the minutes. Having a stable minute-taker goes a long way to = getting them done in a timely and consistent manner. I encourage other WG c= hairs to seek out secretaries for their WGs. Asking a colleague in your own organization can be an easy way = to start.

Cheers,
Andy


On Thu, Mar 21, 2013 at 10:43 AM, Bob Hinden <bob.hinden@gm= ail.com> wrote:

On Mar 21, 2013, at 9:34 AM, Brian E Carpenter wrote:

> On 20/03/2013 20:23, Ted Lemon wrote:
>> On Mar 20, 2013, at 2:44 PM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
>>> 1) at the end of each meeting, if the wg etherpad contains mor= e than 500 characters, then it is considered potential minutes.
>>> 2) after one week, an automated tool takes this etherpad and p= ut it into meeting materials as wg minutes and send an email to the wg chai= rs and wg mailing list saying what it did.
>>> 3) wg chairs can always push another version, since they will = have an opportunity.
>>> 4) at the cutoff for proceedings, they become official minutes= .
>>
>> This seems like it would produce more bad results than good result= s
>
> Definitely. A rough transcript is not the same things as minutes.
> Minutes are supposed to be a comprehensible summary of points made
> and conclusions reached. There is no easy way to produce good minutes;=
> it's hard work.

That's my view as well.  We have the jabber logs for a rough transcrip= t of the meeting.

If the chairs of a working group consistently don't produce minutes by the = deadline, then the ADs should get new w.g. chairs.

Bob



--_000_C1274F318AAD4D2D8951C0C8354CF3F5ericssoncom_-- From henrik@levkowetz.com Fri Apr 5 02:39:00 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7172621F86DC for ; Fri, 5 Apr 2013 02:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+n8m2MNDUQp for ; Fri, 5 Apr 2013 02:38:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A4D2221F96BF for ; Fri, 5 Apr 2013 02:38:59 -0700 (PDT) Received: from [2a01:3f0:1:0:1523:d481:1dc0:e7e1] (port=64214 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1UO36h-00010o-Jn; Fri, 05 Apr 2013 11:38:51 +0200 Message-ID: <515E9BAB.5010300@levkowetz.com> Date: Fri, 05 Apr 2013 11:38:51 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott O Bradner References: <2466153C-7E56-45FC-8C44-7853B1C7EC0D@cisco.com> <62E4DBAC-E248-4610-9293-FB4FCA890BD1@sobco.com> In-Reply-To: <62E4DBAC-E248-4610-9293-FB4FCA890BD1@sobco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:1523:d481:1dc0:e7e1 X-SA-Exim-Rcpt-To: sob@sobco.com, cabo@tzi.org, tools-discuss@ietf.org, dwing@cisco.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Cc: Carsten Bormann , Dan Wing , Tools Team Discussion Subject: Re: [Tools-discuss] uppercase/lowercase for 7 files on rsync.tools.ietf.org X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:39:00 -0000 On 2013-03-28 11:31 Scott O Bradner said: > seems that it would be a good idea for the ID tool to force lower case > in file names to fix this sort of thing Yes. It's been enforced for a long time now, but old sins are never forgotten, in this case. Best regards, Henrik > Scott > > On Mar 27, 2013, at 11:28 PM, Carsten Bormann wrote: > >> On Mar 28, 2013, at 03:46, Dan Wing wrote: >> >>> uppercase/lowercase change >> >> Your local file system is case insensitive. >> But there are pairs of files in the Internet-drafts directory that differ only in case. >> Both files map to the same file on your system. >> So each time rsync runs, it finds a file that differs from the local file and overwrites it. >> Next time, it notices that the other file does not match your local file and overwrites it with that. >> I laughed out loud when I first noticed this... >> >> Grüße, Carsten >> >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > From paf@frobbit.se Fri Apr 5 03:19:22 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8EC21F96BB for ; Fri, 5 Apr 2013 03:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm0zXyzWpguT for ; Fri, 5 Apr 2013 03:19:21 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0221F961B for ; Fri, 5 Apr 2013 03:19:20 -0700 (PDT) Received: from [10.196.193.6] (1-193.icannmeeting.org [199.91.193.1]) by mail.frobbit.se (Postfix) with ESMTPSA id 5AFEA219D4; Fri, 5 Apr 2013 12:19:16 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <515E9BAB.5010300@levkowetz.com> Date: Fri, 5 Apr 2013 18:19:15 +0800 Content-Transfer-Encoding: 7bit Message-Id: <225CB990-B94D-483B-8326-07C2491539B0@frobbit.se> References: <2466153C-7E56-45FC-8C44-7853B1C7EC0D@cisco.com> <62E4DBAC-E248-4610-9293-FB4FCA890BD1@sobco.com> <515E9BAB.5010300@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.1503) Cc: Carsten Bormann , Dan Wing , Scott O Bradner , Tools Team Discussion Subject: Re: [Tools-discuss] uppercase/lowercase for 7 files on rsync.tools.ietf.org X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 10:19:22 -0000 On 5 apr 2013, at 17:38, Henrik Levkowetz wrote: > Yes. It's been enforced for a long time now, but old sins are never > forgotten, in this case. Its Friday: *this* case? Is that upper or lower? :-P Patrik From henrik@levkowetz.com Fri Apr 5 03:22:23 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1454421F9744 for ; Fri, 5 Apr 2013 03:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqby0lTJwWbg for ; Fri, 5 Apr 2013 03:22:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1A21F972C for ; Fri, 5 Apr 2013 03:22:22 -0700 (PDT) Received: from [2a01:3f0:1:0:1523:d481:1dc0:e7e1] (port=64695 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1UO3me-00027h-KU; Fri, 05 Apr 2013 12:22:12 +0200 Message-ID: <515EA5D4.90001@levkowetz.com> Date: Fri, 05 Apr 2013 12:22:12 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <2466153C-7E56-45FC-8C44-7853B1C7EC0D@cisco.com> <62E4DBAC-E248-4610-9293-FB4FCA890BD1@sobco.com> <515E9BAB.5010300@levkowetz.com> <225CB990-B94D-483B-8326-07C2491539B0@frobbit.se> In-Reply-To: <225CB990-B94D-483B-8326-07C2491539B0@frobbit.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:1523:d481:1dc0:e7e1 X-SA-Exim-Rcpt-To: paf@frobbit.se, sob@sobco.com, cabo@tzi.org, dwing@cisco.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Cc: Carsten Bormann , Dan Wing , Scott O Bradner , Tools Team Discussion Subject: Re: [Tools-discuss] uppercase/lowercase for 7 files on rsync.tools.ietf.org X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 10:22:23 -0000 On 2013-04-05 12:19 Patrik Fältström said: > > On 5 apr 2013, at 17:38, Henrik Levkowetz wrote: > >> Yes. It's been enforced for a long time now, but old sins are never >> forgotten, in this case. > > Its Friday: > > *this* case? Is that upper or lower? Ok, I'll bite: .. in *these* cases :-) Henrik From henrik@levkowetz.com Fri Apr 5 05:25:03 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCB721F976A for ; Fri, 5 Apr 2013 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y38TnFIeOft9 for ; Fri, 5 Apr 2013 05:25:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9080321F9769 for ; Fri, 5 Apr 2013 05:25:02 -0700 (PDT) Received: from [2a01:3f0:1:0:1523:d481:1dc0:e7e1] (port=65460 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1UO5hQ-0007yU-Na; Fri, 05 Apr 2013 14:24:57 +0200 Message-ID: <515EC298.9010207@levkowetz.com> Date: Fri, 05 Apr 2013 14:24:56 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <5151D38D.60207@stpeter.im> In-Reply-To: <5151D38D.60207@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2RKFUCSJDXGNHDUADQCEL" X-SA-Exim-Connect-IP: 2a01:3f0:1:0:1523:d481:1dc0:e7e1 X-SA-Exim-Rcpt-To: stpeter@stpeter.im, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Cc: Tools Team Discussion Subject: Re: [Tools-discuss] missing WG X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 12:25:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RKFUCSJDXGNHDUADQCEL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter, I just saw your note (below) to the list. (However, it's much better to send a note to me or to (essentially the same) webmaster@tools.ietf.org) if you want to get immediate attention...) Anyway: The reason for this was a bug in the fairly new charter support in the datatracker, where not all state information for the WG in question was generated correctly when a charter was marked as approved. This resulted in the jcardcal WG not being mentioned in various places; in particular it was missing in http://datatracker.ietf.org/wg/1wg-summary.txt I've now fixed the bug in the datatracker, so this should not repeat for new WGs; I've also fixed the database for jcardcal so the scripts on tools.ietf.org will do their thing, and create the page. On 2013-03-26 17:57 Peter Saint-Andre said: > The JCARDCAL WG shows up on datatracker.ietf.org but not on > tools.ietf.org... >=20 > https://datatracker.ietf.org/wg/jcardcal/ > https://tools.ietf.org/wg/jcardcal/ >=20 > How in-sync is tools.ietf.org supposed to be? You should never have to wait more than an hour to see changes. For some pages, maximum delay is as little as 3 minutes. > And if tools.ietf.org is no longer canonical, what about add-on tools > such as the issue tracker? This was a bug; there's no intention of not keeping tools.ietf.org in sync going forward. Not only that; I'm working at several strategies to improve latency substantially. Best regards, Henrik ------enig2RKFUCSJDXGNHDUADQCEL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJRXsKYAAoJEE6bV0uPuxcac/kQAIRAiX1FbhWA4WDHN/FxdtUI eaxHRQgD08wKZD8RgOTpzHTLvdvSSGStSro80S2jHN1rWzbI664QZg1OEplZyRGI C5WyIEGsUJmq7gw7nkzzcwdYEZNpmKeKQJdA6Ww4VjxR5l5m791bnrWttJGGWqhb 3kzjQRM1W440bpEjdw0PdmJU2cen6GN+uK5SWHZOhZtdzI63byahFPetBHlIFiwC XO9xDOL9ovMm5yNNLCtD72o3vGimVt0Ueii8ADVrYT37BWws3VxB66PgLKVMzZGV kCfz/zAyfpXYgGrZvLKBgeIisjIPt+ebhd/g8G7GD/17bPWM3AvEwo4VYJg1sdRY E/vUT/d7VTuq24b3TW2FKRlKCVN8CR6wyl88550P6P1WIZerQHk/kc3/YzDtuEMl GxltWTUace06JzifytRQxmDHAIXY2+mT2OMolLp2WkHB1IW9KGKRMfNK6WwevITm nElBdo4BQWEMx/R5DVUa9B4Kl9HbUA+x6R/tKTUYT6ao6H8MeKUY0N1EvOjvLzA7 G64rLT7Gl5lIcH/eFCjwhFtvjdd78jpEsUvvLWa4vEmK82s9S6Kikz4b9PYuuXOa YK/kt96i2//6gUXQMiPbFv0nz0LfsF65yGKoignmsQdkLpc/Qi/AIZAT4iR0Xh3w yJPO40uzEe244v4MkwrC =SXki -----END PGP SIGNATURE----- ------enig2RKFUCSJDXGNHDUADQCEL-- From dwing@cisco.com Sat Apr 6 09:28:48 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF221F8644 for ; Sat, 6 Apr 2013 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.103 X-Spam-Level: X-Spam-Status: No, score=-110.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2RoQenino60 for ; Sat, 6 Apr 2013 09:28:47 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7175421F8640 for ; Sat, 6 Apr 2013 09:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1581; q=dns/txt; s=iport; t=1365265727; x=1366475327; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MYVG+cjy1Yf4pbDmr8HwrmLm0cEwu+Q0bzpxaaJrgQM=; b=fluGrv7eccaw2kjhNO2HM/o9c/9P4G8qMtvMdFUFc8coVk+jwFL4sdHs 0P5QxMB7s1NIHS7sxJN77U2efPaYr3hLb1jNRc4z1dGUwaPtzgt50wTlF RnVcEdy8l4g0XDQzkmrOuHRRde4qKbBCdubh/3PzGyJcYX3+OBeKW8kv9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FALZMYFGrRDoH/2dsb2JhbABRgwY2AcEggQIWdIIfAQEBAwEBAQFrCwULCxguJzAGE4gOBQ2+b45wMweCYGEDiH6NdoEhhGKLC4MrHA X-IronPort-AV: E=Sophos;i="4.87,421,1363132800"; d="scan'208";a="77929027" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Apr 2013 16:28:47 +0000 Received: from [10.21.74.54] ([10.21.74.54]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r36GSekV004042; Sat, 6 Apr 2013 16:28:45 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <515E9BAB.5010300@levkowetz.com> Date: Fri, 5 Apr 2013 20:13:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2466153C-7E56-45FC-8C44-7853B1C7EC0D@cisco.com> <62E4DBAC-E248-4610-9293-FB4FCA890BD1@sobco.com> <515E9BAB.5010300@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.1503) Cc: Carsten Bormann , Tools Team Discussion , Scott O Bradner Subject: Re: [Tools-discuss] uppercase/lowercase for 7 files on rsync.tools.ietf.org X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 16:28:48 -0000 On Apr 5, 2013, at 2:38 AM, Henrik Levkowetz = wrote: >=20 > On 2013-03-28 11:31 Scott O Bradner said: >> seems that it would be a good idea for the ID tool to force lower = case >> in file names to fix this sort of thing >=20 > Yes. It's been enforced for a long time now, but old sins are never > forgotten, in this case. I added a few more --exclude lines to skip over those cAsEs, so my = problem is solved. -d > Best regards, >=20 > Henrik >=20 >=20 >> Scott >>=20 >> On Mar 27, 2013, at 11:28 PM, Carsten Bormann wrote: >>=20 >>> On Mar 28, 2013, at 03:46, Dan Wing wrote: >>>=20 >>>> uppercase/lowercase change >>>=20 >>> Your local file system is case insensitive. =20 >>> But there are pairs of files in the Internet-drafts directory that = differ only in case. >>> Both files map to the same file on your system. >>> So each time rsync runs, it finds a file that differs from the local = file and overwrites it. =20 >>> Next time, it notices that the other file does not match your local = file and overwrites it with that. >>> I laughed out loud when I first noticed this... >>>=20 >>> Gr=FC=DFe, Carsten >>>=20 >>> _______________________________________________ >>> Tools-discuss mailing list >>> Tools-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-discuss >>=20 >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss >>=20 From bclaise@cisco.com Thu Apr 11 05:49:21 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F021F8528 for ; Thu, 11 Apr 2013 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbYV+9IgdfKk for ; Thu, 11 Apr 2013 05:49:21 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BCAA421F8525 for ; Thu, 11 Apr 2013 05:49:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BCnJri021578 for ; Thu, 11 Apr 2013 14:49:19 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BCmr1G021863; Thu, 11 Apr 2013 14:49:04 +0200 (CEST) Message-ID: <5166B0E3.6070103@cisco.com> Date: Thu, 11 Apr 2013 14:47:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tools Team Discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: me Subject: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 12:49:21 -0000 Hi there, Each time there is a new charter discussion, I want to compare the new charter proposal with the charter currently used in the WG. However, I sometimes see a mismatch in the version. Let's take an example https://datatracker.ietf.org/doc/charter-ietf-jose/history/ In the From field, I have the choice between 2013-04-08, 2013-03-22, and 2011-09-21. When I check the current WG charter at http://tools.ietf.org/wg/jose/charters, I see 2012-08-01 Can you please help. Regards, Benoit From lars@netapp.com Thu Apr 11 06:11:45 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00D021F856F for ; Thu, 11 Apr 2013 06:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALm7Y94u8GR7 for ; Thu, 11 Apr 2013 06:11:44 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37121F856E for ; Thu, 11 Apr 2013 06:11:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,455,1363158000"; d="scan'208";a="39474084" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 11 Apr 2013 06:11:44 -0700 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3BDBhPx029558; Thu, 11 Apr 2013 06:11:44 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 06:11:43 -0700 From: "Eggert, Lars" To: Benoit Claise Thread-Topic: [Tools-discuss] Charter diff feature Thread-Index: AQHONrMQEnfejmG600KWFZ65tiKhx5jRdCwA Date: Thu, 11 Apr 2013 13:11:43 +0000 Message-ID: <7BBBBAD4-0FFF-43E2-9D24-5178C199D119@netapp.com> References: <5166B0E3.6070103@cisco.com> In-Reply-To: <5166B0E3.6070103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:11:45 -0000 Exists on the tools pages, e.g. http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/wg/rmcat/charter= -rmcat-2013-03-13.txt&url2=3Dhttp://tools.ietf.org/wg/rmcat/charter-rmcat-2= 013-04-09.txt Lars On Apr 11, 2013, at 14:47, Benoit Claise wrote: > Hi there, >=20 > Each time there is a new charter discussion, I want to compare the new ch= arter proposal with the charter currently used in the WG. However, I someti= mes see a mismatch in the version. >=20 > Let's take an example > https://datatracker.ietf.org/doc/charter-ietf-jose/history/ > In the From field, I have the choice between 2013-04-08, 2013-03-22, and = 2011-09-21. > When I check the current WG charter at http://tools.ietf.org/wg/jose/char= ters, I see 2012-08-01 >=20 > Can you please help. >=20 > Regards, Benoit >=20 >=20 >=20 > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From bclaise@cisco.com Thu Apr 11 06:18:25 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB24221F8BD0 for ; Thu, 11 Apr 2013 06:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq8F+CSATcjx for ; Thu, 11 Apr 2013 06:18:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B621F8AB0 for ; Thu, 11 Apr 2013 06:18:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BDIOdo024832; Thu, 11 Apr 2013 15:18:24 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BDHivx024786; Thu, 11 Apr 2013 15:17:59 +0200 (CEST) Message-ID: <5166B7A6.7000509@cisco.com> Date: Thu, 11 Apr 2013 15:16:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Eggert, Lars" References: <5166B0E3.6070103@cisco.com> <7BBBBAD4-0FFF-43E2-9D24-5178C199D119@netapp.com> In-Reply-To: <7BBBBAD4-0FFF-43E2-9D24-5178C199D119@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:18:26 -0000 Lars, Yes, but what I want is a diff with 2012-08-01, which appears to be the one the WG uses right now according to http://tools.ietf.org/wg/jose/charters Regards, Benoit > Exists on the tools pages, e.g. > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/wg/rmcat/charter-rmcat-2013-03-13.txt&url2=http://tools.ietf.org/wg/rmcat/charter-rmcat-2013-04-09.txt > > Lars > > On Apr 11, 2013, at 14:47, Benoit Claise wrote: > >> Hi there, >> >> Each time there is a new charter discussion, I want to compare the new charter proposal with the charter currently used in the WG. However, I sometimes see a mismatch in the version. >> >> Let's take an example >> https://datatracker.ietf.org/doc/charter-ietf-jose/history/ >> In the From field, I have the choice between 2013-04-08, 2013-03-22, and 2011-09-21. >> When I check the current WG charter at http://tools.ietf.org/wg/jose/charters, I see 2012-08-01 >> >> Can you please help. >> >> Regards, Benoit >> >> >> >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss > > From paul.hoffman@vpnc.org Thu Apr 11 06:43:34 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107B21F8C1E for ; Thu, 11 Apr 2013 06:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J7l28LTj6Zt for ; Thu, 11 Apr 2013 06:43:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D09E221F8C06 for ; Thu, 11 Apr 2013 06:43:33 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3BDhWG2052150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Apr 2013 06:43:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <884A2ED8-B968-4033-9AD7-7F9E3A58A397@vpnc.org> Date: Thu, 11 Apr 2013 06:43:33 -0700 To: Tools Team Discussion Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [Tools-discuss] Tool for marking a personal document as replaced by a WG doc? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:43:34 -0000 Greetings again. Last year, Robert Sparks was meant to put on the Tools = Team request list an item to make it so that we chairs could mark an I-D = in the Datatracker as having been replaced by a WG document. However, I = don't see such a tool at . Did = the tool get created? --Paul Hoffman= From olau@iola.dk Thu Apr 11 07:46:16 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BCB21F8F28 for ; Thu, 11 Apr 2013 07:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVtOgQVACWnV for ; Thu, 11 Apr 2013 07:46:16 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4E21F8F29 for ; Thu, 11 Apr 2013 07:46:15 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jz10so1498285veb.33 for ; Thu, 11 Apr 2013 07:46:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=jsseCAEJJWRUP4BeLZfX09FkavpFjgcywZCrgZ9rT1s=; b=U4j8obiP+1+kYQd8AF28szoTLzyCdS021vCPPoaq6eDjkQJelpaAy+QidobcP4RFac H3Qyks4jrVl4OX2Zz2wnP4qVCg1pVHRNoTCYvIGXjFEEajls44HWWwOplDPkqopusaIp +PJgZcXhSvd8YIdjCcnpR0f7+NcnmHOezvbE+9Xnl1RwwGR7t3d6b3bPqakI1k/iQaNL hOUmpgpjYI8YQNIdhoaALsKcoarpry6RG7/5XlzOq23cBdh6LW7eVcfhKB7Zfiq/3YAC KiR5wO2gpSMduGAe/I+pKwcFfkDSVy8I9X881cmBdApXh04TpXVfwCkC7To8u+1Mo+Pv wDyQ== X-Received: by 10.220.19.8 with SMTP id y8mr5310101vca.31.1365691574750; Thu, 11 Apr 2013 07:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.96.79 with HTTP; Thu, 11 Apr 2013 07:45:53 -0700 (PDT) In-Reply-To: <5166B0E3.6070103@cisco.com> References: <5166B0E3.6070103@cisco.com> From: Ole Laursen Date: Thu, 11 Apr 2013 16:45:53 +0200 Message-ID: To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmCKGYJg3jvMGWOp2AVdEpfjyC94h7SnFtczVWxt6zqyC1N5PTSA/v7Hy/MiNZAtV3yPaD4 Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:46:16 -0000 2013/4/11 Benoit Claise : > Let's take an example > https://datatracker.ietf.org/doc/charter-ietf-jose/history/ > In the From field, I have the choice between 2013-04-08, 2013-03-22, and > 2011-09-21. > When I check the current WG charter at > http://tools.ietf.org/wg/jose/charters, I see 2012-08-01 It looks to me as if it is actually the same charter? My guess is that the tools server and the Datatracker database has a different idea of the timestamp for that charter for some reason. We did an import when the charter tool went up - the details escape me, but I think the Datatracker timestamp is probably the correct one in this case. In any case, charters actually have official sequential revision numbers now rather than the timestamps. Ole From rjsparks@nostrum.com Thu Apr 11 07:51:20 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5003621F88A0 for ; Thu, 11 Apr 2013 07:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF0mEKJgmLMT for ; Thu, 11 Apr 2013 07:51:19 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2721F888B for ; Thu, 11 Apr 2013 07:51:19 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3BEpHP7050766 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Thu, 11 Apr 2013 09:51:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5166CDE4.2080900@nostrum.com> Date: Thu, 11 Apr 2013 09:51:16 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <884A2ED8-B968-4033-9AD7-7F9E3A58A397@vpnc.org> In-Reply-To: <884A2ED8-B968-4033-9AD7-7F9E3A58A397@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Subject: Re: [Tools-discuss] Tool for marking a personal document as replaced by a WG doc? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:51:20 -0000 On 4/11/13 8:43 AM, Paul Hoffman wrote: > Greetings again. Last year, Robert Sparks was meant to put on the Tools Team request list an item to make it so that we chairs could mark an I-D in the Datatracker as having been replaced by a WG document. However, I don't see such a tool at . Did the tool get created? No Paul - that's still an outstanding request. For the moment, chairs still need to send email to the secretary to capture that relation. I'm not finding the corresponding ticket quickly though - I'll keep digging and create a new one if necessary. If you can send me a pointer to our earlier conversation, I'd appreciate it (so I can be sure I captured the entire idea correctly). RjS > > --Paul Hoffman > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From paul.hoffman@vpnc.org Thu Apr 11 08:16:56 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F320021F8F41 for ; Thu, 11 Apr 2013 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fYOlxLvEZ-q for ; Thu, 11 Apr 2013 08:16:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 584B521F8D8D for ; Thu, 11 Apr 2013 08:16:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3BFGrde056048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 08:16:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <5166CDE4.2080900@nostrum.com> Date: Thu, 11 Apr 2013 08:16:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <884A2ED8-B968-4033-9AD7-7F9E3A58A397@vpnc.org> <5166CDE4.2080900@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1503) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Tool for marking a personal document as replaced by a WG doc? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 15:16:56 -0000 On Apr 11, 2013, at 7:51 AM, Robert Sparks wrote: > On 4/11/13 8:43 AM, Paul Hoffman wrote: >> Greetings again. Last year, Robert Sparks was meant to put on the = Tools Team request list an item to make it so that we chairs could mark = an I-D in the Datatracker as having been replaced by a WG document. = However, I don't see such a tool at = . Did the tool get created? > No Paul - that's still an outstanding request. For the moment, chairs = still need to send email to the secretary to capture that relation. > I'm not finding the corresponding ticket quickly though - I'll keep = digging and create a new one if necessary. If you can send me a pointer = to our earlier conversation, I'd appreciate it (so I can be sure I = captured the entire idea correctly). Thread on wg-chairs from last year titled "What should happen when a WG = adopts an individual I-D?" --Paul Hoffman= From rjsparks@nostrum.com Thu Apr 11 09:00:28 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53C521F91BC for ; Thu, 11 Apr 2013 09:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-8MQx3Fqh4U for ; Thu, 11 Apr 2013 09:00:27 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE90121F91C9 for ; Thu, 11 Apr 2013 09:00:26 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3BG0MRa058645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 11 Apr 2013 11:00:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5166DE16.7010103@nostrum.com> Date: Thu, 11 Apr 2013 11:00:22 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <884A2ED8-B968-4033-9AD7-7F9E3A58A397@vpnc.org> <5166CDE4.2080900@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Tool for marking a personal document as replaced by a WG doc? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:00:28 -0000 On 4/11/13 10:16 AM, Paul Hoffman wrote: > On Apr 11, 2013, at 7:51 AM, Robert Sparks wrote: > >> On 4/11/13 8:43 AM, Paul Hoffman wrote: >>> Greetings again. Last year, Robert Sparks was meant to put on the Tools Team request list an item to make it so that we chairs could mark an I-D in the Datatracker as having been replaced by a WG document. However, I don't see such a tool at . Did the tool get created? >> No Paul - that's still an outstanding request. For the moment, chairs still need to send email to the secretary to capture that relation. >> I'm not finding the corresponding ticket quickly though - I'll keep digging and create a new one if necessary. If you can send me a pointer to our earlier conversation, I'd appreciate it (so I can be sure I captured the entire idea correctly). > Thread on wg-chairs from last year titled "What should happen when a WG adopts an individual I-D?" Thanks. I reread the thread, and while the idea of having a way for a WG chair to use the datatracker to set this relationship came up early, it wasn't what I talked about making a ticket for on the thread. Rather, it was about replaces and replaced by showing up in a similar place (which has been addressed ). In any case, I'll go add a ticket now so we can work on making capturing replaces information easier for the chairs. Let me know if I've missed something. RjS > > --Paul Hoffman From bclaise@cisco.com Thu Apr 11 10:17:25 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5721F8C55 for ; Thu, 11 Apr 2013 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWqRZ4KLm-77 for ; Thu, 11 Apr 2013 10:17:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BD68C21F8C30 for ; Thu, 11 Apr 2013 10:17:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BHHNsG019583; Thu, 11 Apr 2013 19:17:23 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3BHGhRb027886; Thu, 11 Apr 2013 19:16:58 +0200 (CEST) Message-ID: <5166EFA7.20307@cisco.com> Date: Thu, 11 Apr 2013 19:15:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Laursen References: <5166B0E3.6070103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 17:17:25 -0000 On 11/04/2013 16:45, Ole Laursen wrote: > 2013/4/11 Benoit Claise : >> Let's take an example >> https://datatracker.ietf.org/doc/charter-ietf-jose/history/ >> In the From field, I have the choice between 2013-04-08, 2013-03-22, and >> 2011-09-21. >> When I check the current WG charter at >> http://tools.ietf.org/wg/jose/charters, I see 2012-08-01 > It looks to me as if it is actually the same charter? > > My guess is that the tools server and the Datatracker database has a > different idea of the timestamp for that charter for some reason. We > did an import when the charter tool went up - the details escape me, > but I think the Datatracker timestamp is probably the correct one in > this case. > > In any case, charters actually have official sequential revision > numbers now rather than the timestamps. Thanks, that's the trick: focus on the charter revision, and not the dates. Regards, Benoit > > > Ole > > From richard.barnes@gmail.com Thu Apr 11 12:34:12 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4E21F85C4 for ; Thu, 11 Apr 2013 12:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJhCz-Asfsxr for ; Thu, 11 Apr 2013 12:34:11 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id E6D6E21F8576 for ; Thu, 11 Apr 2013 12:34:10 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id kq13so1066071pab.15 for ; Thu, 11 Apr 2013 12:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qWTl05uRfMzZhTP3uGNR7HE8YEpj8BLuL2NrZ7a/kao=; b=O6UDHyVLzxPAgfhtWo2DYnJ0FypCvNSUbWdZL4CFZcHQZVZVjnxCkFCShaajr8qoOj BBV7DL9qjAjLJR5w1fEyvmAU8OnXDN2vUUyM9iy6DXOpIC5zOfGTSqEpPwlfg2mre3eH hSohD+ewisIQKbtvbudqWL1Qg0hHnJ2Kntn3HSkMYYLDD1yVFBWSIgmUNSVrROPzB2PC oiXpVj6wgxoIKm4DWsXrHG3M59uIMKcNo2XvpHdK4oEWFhpJS8STyIE5uFyzZPOXz0k2 2uZlp+pbCeTIu1i2gBv/kwz7MZBaWioRZH4o+9sUNzDZiFfQ6NNN1iJuilKdQUmLjK9X dCkQ== MIME-Version: 1.0 X-Received: by 10.66.7.202 with SMTP id l10mr2128329paa.176.1365708850678; Thu, 11 Apr 2013 12:34:10 -0700 (PDT) Received: by 10.68.118.205 with HTTP; Thu, 11 Apr 2013 12:34:10 -0700 (PDT) Date: Thu, 11 Apr 2013 15:34:10 -0400 Message-ID: From: Richard Barnes To: Tools Team Discussion Content-Type: multipart/alternative; boundary=bcaec520ea99e9612d04da1ade8d Subject: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:34:12 -0000 --bcaec520ea99e9612d04da1ade8d Content-Type: text/plain; charset=ISO-8859-1 On the IESG agenda page, the overlays with the document ballots use a div with "overflow-y: scroll;" That's fine, but on iOS it causes the page to scroll very slowly. Could we please add an additional CSS attribute to those divs, "-webkit-overflow-scrolling: touch"? Thanks, --Richard --bcaec520ea99e9612d04da1ade8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On the IESG agenda page, the overlays with the document ba= llots use a div with "overflow-y: scroll;" =A0That's fine, bu= t on iOS it causes the page to scroll very slowly. Could we please add an a= dditional CSS attribute to those divs, "-webkit-overflow-scrolling: to= uch"?


Thanks,
--R= ichard
--bcaec520ea99e9612d04da1ade8d-- From adam@nostrum.com Thu Apr 11 12:50:56 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0421F8FE5 for ; Thu, 11 Apr 2013 12:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q53uTGoetIu for ; Thu, 11 Apr 2013 12:50:54 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8795621F8FDC for ; Thu, 11 Apr 2013 12:50:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3BJoesP084732 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 14:50:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51671410.2020100@nostrum.com> Date: Thu, 11 Apr 2013 14:50:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:50:56 -0000 On 4/11/13 14:34, Richard Barnes wrote: > On the IESG agenda page, the overlays with the document ballots use a > div with "overflow-y: scroll;" That's fine, but on iOS it causes the > page to scroll very slowly. Could we please add an additional CSS > attribute to those divs, "-webkit-overflow-scrolling: touch"? > > > http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ /a From Ted.Lemon@nominum.com Thu Apr 11 13:22:56 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1104E21F8F28 for ; Thu, 11 Apr 2013 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31bvnkzVWaEA for ; Thu, 11 Apr 2013 13:22:55 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5921F8F06 for ; Thu, 11 Apr 2013 13:22:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUWcbnpyjckk8NwwUcto6ZkvQBTbVkt9e@postini.com; Thu, 11 Apr 2013 13:22:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AA6541B8094 for ; Thu, 11 Apr 2013 13:22:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A3D4E190061; Thu, 11 Apr 2013 13:22:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 13:22:54 -0700 From: Ted Lemon To: Adam Roach Thread-Topic: [Tools-discuss] Proper scrolling in iOS Thread-Index: AQHONuuNN/vJfzB4SU+aCo+mQayZc5jR4zEAgAAJAYA= Date: Thu, 11 Apr 2013 20:22:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> References: <51671410.2020100@nostrum.com> In-Reply-To: <51671410.2020100@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <70969DC3F6FB1F4C9C554B7DC32EB758@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , Tools Team Discussion Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:22:56 -0000 On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: > http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ I think this argues for leaving in the standard css, not for leaving out th= e webkit css. From nico@cryptonector.com Thu Apr 11 13:52:35 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444021F87D5 for ; Thu, 11 Apr 2013 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJn2cmheA-rY for ; Thu, 11 Apr 2013 13:52:34 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 283DE21F8952 for ; Thu, 11 Apr 2013 13:52:34 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id D4D4DBC04A for ; Thu, 11 Apr 2013 13:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7tahm26N9jwqCrA+a6GA uxrCzpM=; b=L68/anpCfEsUIT+wzVBnHrZTp5JNn7Z6ETIt8udEI/gmsGm5SP1g JmhNGDYBf/fM2VvSi6xOLEfD3w4HWa46gcTiF+xENXmtkyC2hUFL1eO/3rBqrYr7 r+CuQ+poL2b6Sc4CAyM8lN0qJ3BVYknn9EidoxXLfb4o7EscdueRqTE= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 5965DBC042 for ; Thu, 11 Apr 2013 13:52:33 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s43so1515201wey.21 for ; Thu, 11 Apr 2013 13:52:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr19470wik.16.1365713552147; Thu, 11 Apr 2013 13:52:32 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Thu, 11 Apr 2013 13:52:32 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> References: <51671410.2020100@nostrum.com> <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> Date: Thu, 11 Apr 2013 15:52:32 -0500 Message-ID: From: Nico Williams To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Cc: Richard Barnes , Tools Team Discussion Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:52:35 -0000 On Thu, Apr 11, 2013 at 3:22 PM, Ted Lemon wrote: > On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: >> http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ > > I think this argues for leaving in the standard css, not for leaving out the webkit css. Or using the user agent string to figure out what CSS to send. Nico -- From julian.reschke@gmx.de Thu Apr 11 14:07:58 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205AB21F8FE5 for ; Thu, 11 Apr 2013 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGBdnF1V0Uf9 for ; Thu, 11 Apr 2013 14:07:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 458DC21F8917 for ; Thu, 11 Apr 2013 14:07:49 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LdKAB-1Uqcrm42mP-00iQib for ; Thu, 11 Apr 2013 23:07:44 +0200 Received: (qmail invoked by alias); 11 Apr 2013 21:07:43 -0000 Received: from p54BB28A8.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.40.168] by mail.gmx.net (mp030) with SMTP; 11 Apr 2013 23:07:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18T3iYYyt8TErZ+4v4FloPFgAk3KELNEg7TnT0aYQ 0qDFWn4JkvvND6 Message-ID: <5167261A.2000603@gmx.de> Date: Thu, 11 Apr 2013 23:07:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Nico Williams References: <51671410.2020100@nostrum.com> <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Tools Team Discussion , Richard Barnes Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:07:58 -0000 On 2013-04-11 22:52, Nico Williams wrote: > On Thu, Apr 11, 2013 at 3:22 PM, Ted Lemon wrote: >> On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: >>> http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ >> >> I think this argues for leaving in the standard css, not for leaving out the webkit css. > > Or using the user agent string to figure out what CSS to send. > ... Nooooo. Just use a device where you have an actual choice of browsers. Best regards, Julian From olau@iola.dk Thu Apr 11 14:15:49 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7756111E80C5 for ; Thu, 11 Apr 2013 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH4Vbo5xxvPI for ; Thu, 11 Apr 2013 14:15:48 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8683811E80BF for ; Thu, 11 Apr 2013 14:15:48 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d4so1000895eek.29 for ; Thu, 11 Apr 2013 14:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=4Gj3rZtWAcexErRzmTQCzHfoiX7sSupFJQ7hhrlR/iY=; b=G+tKjTPoUOQEaCSD6Ht6+beFpYBtXAXJJb1r20lawFjMbZICrLcva0GqZ3EoKxyjLu G9xiCDnUXLg+NNn+82erNbi5QT9msDJQpO0jlZ5Ud0g6heYjjByyfEq+eTr82UOxUA27 JA0iqWGvOJTLw4N9py0642vba2JKtBP2RMPsLJBZVWmNJcZ93nKhrzZQGmAyugNl2XxN hUYI5iWlj0zQWgqzeNgSRwa0aAwWXLKn+sVdsdiqkykARHQVjoEBZM7JEL8fw3mvWj9+ rxFas7tWt6NmgrJqW1exMFiA/4GqI0BifXzOSNztnAN+ZKHKc7gE5jvp0Zl0SL65c4Ot ye6A== X-Received: by 10.15.99.201 with SMTP id bl49mr20540726eeb.43.1365714947540; Thu, 11 Apr 2013 14:15:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.79.147 with HTTP; Thu, 11 Apr 2013 14:15:27 -0700 (PDT) In-Reply-To: References: From: Ole Laursen Date: Thu, 11 Apr 2013 23:15:27 +0200 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmWdgD7r0TeonD3y8npgiWnsmERb98JFCXAwBwf4mZSg7Kb03uR/yzw4chEtc0s13kZ+Kec Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:15:49 -0000 2013/4/11 Richard Barnes : > On the IESG agenda page, the overlays with the document ballots use a div > with "overflow-y: scroll;" That's fine, but on iOS it causes the page to > scroll very slowly. Could we please add an additional CSS attribute to those > divs, "-webkit-overflow-scrolling: touch"? > > I've recently rewritten the popups on my cleanup branch (this should also allow you to open the ballots in a new tab), but I'm guessing you'd have the same problem. So I've added that statement to the CSS in my repository. I'll have to try it on an iOS device to see what happens. What I don't understand is why the Webkit team at Apple just don't fix this once and for all. Ole From nico@cryptonector.com Thu Apr 11 15:08:27 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F8021F898A for ; Thu, 11 Apr 2013 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUy8wUlQyeeT for ; Thu, 11 Apr 2013 15:08:26 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C20E521F8976 for ; Thu, 11 Apr 2013 15:08:26 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 8DD5A1B4058 for ; Thu, 11 Apr 2013 15:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QRAdqtr0P3pHxiqnm1r8 agAK1a4=; b=R3qd5U1Zmt8yz/ienbuVi0tqxVG+bEY3geU33NmHcEAON/xhnTWf JfTNMIlT+nFAXlQBZqUVGeL4yVJketDGSGYMSTyT7sXukcGjXrRH4X+q9gf4yB0U +EHYK/OVk7euZXP/7l2v8It/VpNxqnEPp6oerQBFdYsLHACbcgvhxoE= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 4EF411B4061 for ; Thu, 11 Apr 2013 15:08:22 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so1050535wib.9 for ; Thu, 11 Apr 2013 15:08:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr13658981wjb.38.1365718099614; Thu, 11 Apr 2013 15:08:19 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Thu, 11 Apr 2013 15:08:19 -0700 (PDT) In-Reply-To: <5167261A.2000603@gmx.de> References: <51671410.2020100@nostrum.com> <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> <5167261A.2000603@gmx.de> Date: Thu, 11 Apr 2013 17:08:19 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Tools Team Discussion , Richard Barnes Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:08:27 -0000 On Thu, Apr 11, 2013 at 4:07 PM, Julian Reschke wrote: > On 2013-04-11 22:52, Nico Williams wrote: >> >> On Thu, Apr 11, 2013 at 3:22 PM, Ted Lemon wrote: >>> >>> On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: >>>> >>>> http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ >>> >>> >>> I think this argues for leaving in the standard css, not for leaving out >>> the webkit css. >> >> >> Or using the user agent string to figure out what CSS to send. >> ... > > > Nooooo. If there can be vendor-specific prefixes then there must be a conditional somewhere in order to use them, or you must use all of them :) or you must have a vendor-specific site. Pick your poison. > Just use a device where you have an actual choice of browsers. So, if a site looks bad in one browser, switch to a different one, and play this game with every site? /me checks the date. No, it's not April Fool's today. Nico -- From julian.reschke@gmx.de Thu Apr 11 15:38:39 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54FD21F87E9 for ; Thu, 11 Apr 2013 15:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhGQbSmdrfCl for ; Thu, 11 Apr 2013 15:38:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A10A321F87D5 for ; Thu, 11 Apr 2013 15:38:38 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MGDc1-1UK2sV2fm3-00F9II for ; Fri, 12 Apr 2013 00:38:36 +0200 Received: (qmail invoked by alias); 11 Apr 2013 22:38:36 -0000 Received: from p54BB28A8.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.40.168] by mail.gmx.net (mp033) with SMTP; 12 Apr 2013 00:38:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19gKH1pO3tgCIwbWTz+/FN9JPX6i5eSe0NMZMKifc FT/WRKN1ojIKRM Message-ID: <51673B69.4090803@gmx.de> Date: Fri, 12 Apr 2013 00:38:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Nico Williams References: <51671410.2020100@nostrum.com> <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> <5167261A.2000603@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Tools Team Discussion , Richard Barnes Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:38:39 -0000 On 2013-04-12 00:08, Nico Williams wrote: > On Thu, Apr 11, 2013 at 4:07 PM, Julian Reschke wrote: >> On 2013-04-11 22:52, Nico Williams wrote: >>> >>> On Thu, Apr 11, 2013 at 3:22 PM, Ted Lemon wrote: >>>> >>>> On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: >>>>> >>>>> http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ >>>> >>>> >>>> I think this argues for leaving in the standard css, not for leaving out >>>> the webkit css. >>> >>> >>> Or using the user agent string to figure out what CSS to send. >>> ... >> >> >> Nooooo. > > If there can be vendor-specific prefixes then there must be a > conditional somewhere in order to use them, or you must use all of > them :) or you must have a vendor-specific site. Pick your poison. UA sniffing is the worst possible poison. >> Just use a device where you have an actual choice of browsers. > > So, if a site looks bad in one browser, switch to a different one, and > play this game with every site? /me checks the date. No, it's not > April Fool's today. The suggestion was to use a platform where you have a choice. You don't on iOS. Enough said. Best regards, Julian From barryleiba.mailing.lists@gmail.com Thu Apr 11 16:37:19 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EAC21F8573 for ; Thu, 11 Apr 2013 16:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXW2c+if2U+s for ; Thu, 11 Apr 2013 16:37:18 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4521F8546 for ; Thu, 11 Apr 2013 16:37:18 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x19so1682285vbf.38 for ; Thu, 11 Apr 2013 16:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hk2jbAuUxNRMHNe/R9TOBclV6MoW2rWcf+PxDikMiwQ=; b=fazAzvOEDaKLYLaY2JIqb0tGC1OTS5tVAHmKX1A80+271LT5/q3KlacUU6aEtOloJ8 0XnWUGlhHkVDnZLMJ3yUyLW5+Rl4bb1bP4smlZ+mhxPzCQ6XAGS+iMIIRC+cn/+cIYDu OBUEErxaW+yt2dO6+MH82prnA7FuuTKoIXWZqRTSiwOLEWzSKnlhHuLIOPWs/YYoMuqG f55C81Z/SYGHIMTKndg1RopfAoqpnR+LECgZayMDCEWHRCoVRNs5HAlQJTksM0jsTEFg 6pr7h7Quq5/nqPbasR/yveCD94GiK0YVDSGZ+Z8doK2Mw5fKmDsrpkMhrMZDN/hr03Y3 YRYg== MIME-Version: 1.0 X-Received: by 10.220.103.7 with SMTP id i7mr6765026vco.7.1365723437883; Thu, 11 Apr 2013 16:37:17 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 11 Apr 2013 16:37:17 -0700 (PDT) In-Reply-To: <5166EFA7.20307@cisco.com> References: <5166B0E3.6070103@cisco.com> <5166EFA7.20307@cisco.com> Date: Thu, 11 Apr 2013 19:37:17 -0400 X-Google-Sender-Auth: 575_hwnmys-Zs2tkRXooN6iiRIg Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:37:19 -0000 >> My guess is that the tools server and the Datatracker database has a >> different idea of the timestamp for that charter for some reason. We >> did an import when the charter tool went up - the details escape me, >> but I think the Datatracker timestamp is probably the correct one in >> this case. >> >> In any case, charters actually have official sequential revision >> numbers now rather than the timestamps. > > Thanks, that's the trick: focus on the charter revision, and not the dates. Further follow-up: The confusing dates come from the fact that changes that the Secretariat makes that do not affect the charter text (changes to milestones or chairs, for example) cause a "new" charter to appear on the tools WG charter page, though they don't cause a new charter version to appear in the datatracker. Barry From bclaise@cisco.com Fri Apr 12 01:23:41 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14721F8A0C for ; Fri, 12 Apr 2013 01:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShtpduqwutUi for ; Fri, 12 Apr 2013 01:23:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id EED3C21F87B6 for ; Fri, 12 Apr 2013 01:23:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3C8NTIL015149; Fri, 12 Apr 2013 10:23:29 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3C8MoH9002934; Fri, 12 Apr 2013 10:23:06 +0200 (CEST) Message-ID: <5167C45A.4070905@cisco.com> Date: Fri, 12 Apr 2013 10:22:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Barry Leiba References: <5166B0E3.6070103@cisco.com> <5166EFA7.20307@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 08:23:42 -0000 On 12/04/2013 01:37, Barry Leiba wrote: >>> My guess is that the tools server and the Datatracker database has a >>> different idea of the timestamp for that charter for some reason. We >>> did an import when the charter tool went up - the details escape me, >>> but I think the Datatracker timestamp is probably the correct one in >>> this case. >>> >>> In any case, charters actually have official sequential revision >>> numbers now rather than the timestamps. >> Thanks, that's the trick: focus on the charter revision, and not the dates. > Further follow-up: > The confusing dates come from the fact that changes that the > Secretariat makes that do not affect the charter text (changes to > milestones or chairs, for example) cause a "new" charter to appear on > the tools WG charter page, though they don't cause a new charter > version to appear in the datatracker. As an improvement, we could delete the (confusing) dates, and focus only on the versions. Regards, Benoit > > Barry > > From barryleiba@gmail.com Fri Apr 12 06:39:42 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AA21F8765 for ; Fri, 12 Apr 2013 06:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6CBo9PCXNd7 for ; Fri, 12 Apr 2013 06:39:42 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id C4BF621F84E7 for ; Fri, 12 Apr 2013 06:39:41 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id x11so2660731lbi.15 for ; Fri, 12 Apr 2013 06:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xKH94gxei370jAHuAi97JVUknKySa/v0DWZHDxVh+R4=; b=Ru0NLi1QUU4DFKLU6UFf5IPL+ihfIaSHZZbSm31z9mftauymJE5WryWBNUq8cFZUy3 1n9Rs+pjyr7v6WwZwPQ9vhL4hXYyONKhdEKfiB0T94zQ+2y/bWljhx9AsjTBZQ7nPWNo d6HyB4rRVHOhGjakmxZRvS0TL0DLqemEjnYQg7kMZj6v6A1GD9yf7Euubzvu3gMMNJyG pAZ5kveOuQUh4ihAXK5lhBayGxfLiPjmVt48+NieBHBzveE7beRf9jXai4YIeA26gXhz ozWelDvQX0dMmrgjljvSW/Z9iTfkFEDkJ5SJ9NG2/N3qwm2tWTKrAhoBqXKNtC5ssvSK hG0w== MIME-Version: 1.0 X-Received: by 10.112.129.38 with SMTP id nt6mr5416203lbb.7.1365773980746; Fri, 12 Apr 2013 06:39:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Fri, 12 Apr 2013 06:39:40 -0700 (PDT) In-Reply-To: <5167C45A.4070905@cisco.com> References: <5166B0E3.6070103@cisco.com> <5166EFA7.20307@cisco.com> <5167C45A.4070905@cisco.com> Date: Fri, 12 Apr 2013 09:39:40 -0400 X-Google-Sender-Auth: -jySSjqnpqJE535nX44tSk-kONg Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Charter diff feature X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:39:42 -0000 >> The confusing dates come from the fact that changes that the >> Secretariat makes that do not affect the charter text (changes to >> milestones or chairs, for example) cause a "new" charter to appear on >> the tools WG charter page, though they don't cause a new charter >> version to appear in the datatracker. > > As an improvement, we could delete the (confusing) dates, and focus only on > the versions. But it's useful to be able to go back through the charter history and see the dates that the milestones and chairs were changed. I think that once people get used to how the version numbering works, this won't be so much of a problem as it is now. We might also consider including the charter version numbers, and/or otherwise highlight changes to the charter text (maybe make the dates "bold" when they coincide with a charter text/version change). b From richard.barnes@gmail.com Fri Apr 12 06:49:18 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D121F86BA for ; Fri, 12 Apr 2013 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.348 X-Spam-Level: X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNmbUjdThSx3 for ; Fri, 12 Apr 2013 06:49:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8305221F8689 for ; Fri, 12 Apr 2013 06:49:17 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so1428136pbc.31 for ; Fri, 12 Apr 2013 06:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BycoWNkmGTFV85ByMhlVkv1GwxxsdFSani8lRuDbBck=; b=YQ1nZt88b0LTTvE+E+HZTjIj5tVpL0kz8iw5CJWX4WCgHuQbW4vMDH3BKkUKIigNAT 93HsM80iv3MIk+4oIV8PV6VusgHUYiZse6vTTHUzC5lH5dprI9YO8ZAVNwD85NmY4NeL 44obxbxa/VjWy+ZJkSoER9GmoESh1vzGFGiXbikEl717hgdcn8xElD/xZ5fp0t17AK/M YrXFwY7oNyBn0h9uQke4kHXfR0dyEBhZaP2cPmcizUSxU3kirYfD5jygw06jekGYZW4m VfuzmOa3EBz4NPel7DQfB4aJAO4nhMQ67MvkCq0WauzJIU135NcP2G4JmwCcg9uUsLc8 l62w== MIME-Version: 1.0 X-Received: by 10.68.185.162 with SMTP id fd2mr14768779pbc.176.1365774557185; Fri, 12 Apr 2013 06:49:17 -0700 (PDT) Received: by 10.68.118.205 with HTTP; Fri, 12 Apr 2013 06:49:16 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> References: <51671410.2020100@nostrum.com> <8D23D4052ABE7A4490E77B1A012B6307751400E4@mbx-01.win.nominum.com> Date: Fri, 12 Apr 2013 09:49:16 -0400 Message-ID: From: Richard Barnes To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd6b1fc530f1d04da2a2b3e Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Proper scrolling in iOS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:49:18 -0000 --047d7bd6b1fc530f1d04da2a2b3e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 4:22 PM, Ted Lemon wrote: > On Apr 11, 2013, at 3:50 PM, Adam Roach wrote: > > http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ > > I think this argues for leaving in the standard css, not for leaving out > the webkit css. > +1 --047d7bd6b1fc530f1d04da2a2b3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 4:22 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
On Apr 11, 2013, at 3:50 PM, Adam Roach <adam@nostrum.com> wrote:
> http://www.webmonkey.com/2012/02/webkit-isnt= -breaking-the-web-you-are/

I think this argues for leaving in the standard css, not for leaving out th= e webkit css.

+1 =A0

--047d7bd6b1fc530f1d04da2a2b3e-- From Chris.Dearlove@baesystems.com Mon Apr 15 02:44:48 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFE21F93A5 for ; Mon, 15 Apr 2013 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc8NY4WZ6pSU for ; Mon, 15 Apr 2013 02:44:47 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 191D021F9394 for ; Mon, 15 Apr 2013 02:44:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,474,1363132800"; d="scan'208";a="279287578" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 15 Apr 2013 10:44:46 +0100 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r3F9ijKJ014180 for ; Mon, 15 Apr 2013 10:44:46 +0100 X-IronPort-AV: E=Sophos;i="4.87,474,1363132800"; d="scan'208";a="13226491" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 15 Apr 2013 10:44:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 10:44:45 +0100 From: "Dearlove, Christopher (UK)" To: Tools Team Discussion Thread-Topic: Internet Draft Submission Thread-Index: Ac45vGBsEMrLCSpLTbiZTzhVSfmGuQ== Date: Mon, 15 Apr 2013 09:44:45 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Tools-discuss] Internet Draft Submission X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:44:48 -0000 I'm trying to update an I-D of which I'm an author. Through finger trouble = (I presume) I submitted the xml as txt, and unsurprisingly it failed IDnits= . Unfortunately I failed to realise this and the nature of the error messag= es made me think I had wrong boilerplate. I missed the opportunity to cance= l then. Now any attempt to update the I-D is blocked. If I upload a new version it = ignores it and only uses the old version. There's a button to send all auth= ors an email to the authorised cancellation page. It doesn't work - and it'= s not just me, I've checked and co-author not getting it either. And I've t= ried more than once. So far nothing except an automated response from ietf-= action. So I think I've found a denial of service attack on the IETF, I could uploa= d broken I-Ds where important work is being done and block the authors bein= g able to update them. More seriously, why this behaviour? I think it should be fairly clear that = if someone (unauthenticated) uploads a document and it's broken, the defaul= t action should not be to retain it and block all further attempts to updat= e that document. Blocking should only be possible once authenticated. If so= meone submits something and it's broken, the response should be "this will = shortly be discarded, unless you authenticate and say you really want this = held waiting for correction". But really, I just want to submit my I-D. Last Friday when I started this. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henrik@levkowetz.com Mon Apr 15 08:51:26 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D334F21F9418 for ; Mon, 15 Apr 2013 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaAzagBJQsik for ; Mon, 15 Apr 2013 08:51:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E23F221F9420 for ; Mon, 15 Apr 2013 08:51:25 -0700 (PDT) Received: from [2a01:3f0:1:0:9ccf:d415:6e13:1c1] (port=60465 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1URlgg-0007Y3-9X; Mon, 15 Apr 2013 17:51:22 +0200 Message-ID: <516C21FA.5020908@levkowetz.com> Date: Mon, 15 Apr 2013 17:51:22 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:9ccf:d415:6e13:1c1 X-SA-Exim-Rcpt-To: Chris.Dearlove@baesystems.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Internet Draft Submission X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:51:27 -0000 Hi Christopher, On 2013-04-15 11:44 Dearlove, Christopher (UK) said: > I'm trying to update an I-D of which I'm an author. Through finger > trouble (I presume) I submitted the xml as txt, and unsurprisingly it > failed IDnits. Unfortunately I failed to realise this and the nature > of the error messages made me think I had wrong boilerplate. I missed > the opportunity to cancel then. > > Now any attempt to update the I-D is blocked. If I upload a new > version it ignores it and only uses the old version. There's a button > to send all authors an email to the authorised cancellation page. It > doesn't work - and it's not just me, I've checked and co-author not > getting it either. And I've tried more than once. So far nothing > except an automated response from ietf-action. If the button to send the authors a link to the cancellation page doesn't work, then we need to fix that. We're looking at that now. I've sent you a message off-list with the relevant link. > So I think I've found a denial of service attack on the IETF, I could > upload broken I-Ds where important work is being done and block the > authors being able to update them. But only if the action to send the page link to the authors is broken. That needs to work. > More seriously, why this behaviour? I think it should be fairly clear > that if someone (unauthenticated) uploads a document and it's broken, > the default action should not be to retain it and block all further > attempts to update that document. Blocking should only be possible > once authenticated. If someone submits something and it's broken, the > response should be "this will shortly be discarded, unless you > authenticate and say you really want this held waiting for > correction". I agree. That's not what the specification (RFC 4228) said, if I remember correctly, but I think that's the right thing to do. > But really, I just want to submit my I-D. Last Friday when I started > this. Understood. You should be able to with the link I sent. Best regards, Henrik From Ted.Lemon@nominum.com Mon Apr 15 10:08:50 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293721F961E for ; Mon, 15 Apr 2013 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySBYOcHy3tZU for ; Mon, 15 Apr 2013 10:08:49 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0921F93CC for ; Mon, 15 Apr 2013 10:08:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUWw0Ic+3vn3NFrKT3M/W2n9bxyf3kXr2@postini.com; Mon, 15 Apr 2013 10:08:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 47C0F1B80E7 for ; Mon, 15 Apr 2013 10:08:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 41E67190061 for ; Mon, 15 Apr 2013 10:08:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 10:08:49 -0700 From: Ted Lemon To: Tools Team Discussion Thread-Topic: Is anyone else noticing issues with meeting minutes? Thread-Index: AQHOOfvlTMnXXvrvDE2OEaYYvPwvew== Date: Mon, 15 Apr 2013 17:08:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514985F@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <926281B953FED34C8089766F771F7EBE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Tools-discuss] Is anyone else noticing issues with meeting minutes? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:08:50 -0000 The minutes for softwire are on the proceedings page at www.ietf.org, but c= an't be reached from the tools web site. From henrik@levkowetz.com Tue Apr 16 02:31:32 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C1D21F9376 for ; Tue, 16 Apr 2013 02:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APixn1IPnj65 for ; Tue, 16 Apr 2013 02:31:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4007F21F9367 for ; Tue, 16 Apr 2013 02:31:32 -0700 (PDT) Received: from [2a01:3f0:1:0:4ca8:ece6:839f:49c1] (port=49586 helo=tannat.netnod.se) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1US2Ed-00028m-1p; Tue, 16 Apr 2013 11:31:31 +0200 Message-ID: <516D1A72.4040901@levkowetz.com> Date: Tue, 16 Apr 2013 11:31:30 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B63077514985F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514985F@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:4ca8:ece6:839f:49c1 X-SA-Exim-Rcpt-To: Ted.Lemon@nominum.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Is anyone else noticing issues with meeting minutes? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 09:31:32 -0000 Hi Ted, On 2013-04-15 19:08 Ted Lemon said: > The minutes for softwire are on the proceedings page at www.ietf.org, > but can't be reached from the tools web site. The secretariat has already started entering ietf-87 agenda information into the database, which triggered a scripts on tools.ietf.org to start processing ietf-87 information, and stop processing ietf-86 information. Fixed. The wg pages on tools.ietf.org should be updated within an hour or so. (For future alerts about stuff on tools.ietf.org which doesn't work as expected, please Cc: me personally, as it increases the chances of timely action dramatically.) Best regards, Henrik From Ted.Lemon@nominum.com Tue Apr 16 06:06:35 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5521F96F3 for ; Tue, 16 Apr 2013 06:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVTDwzyQHwWY for ; Tue, 16 Apr 2013 06:06:35 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id D130221F96F1 for ; Tue, 16 Apr 2013 06:06:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUW1M2sdoJNFf/7XW0t5/x8xkZYRr3uEu@postini.com; Tue, 16 Apr 2013 06:06:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4BCA11B80F8 for ; Tue, 16 Apr 2013 06:06:34 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3D5CA190061; Tue, 16 Apr 2013 06:06:34 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 06:06:34 -0700 From: Ted Lemon To: Henrik Levkowetz Thread-Topic: [Tools-discuss] Is anyone else noticing issues with meeting minutes? Thread-Index: AQHOOfvlTMnXXvrvDE2OEaYYvPwve5jZC7oAgAA8FoA= Date: Tue, 16 Apr 2013 13:06:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514B342@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63077514985F@mbx-01.win.nominum.com> <516D1A72.4040901@levkowetz.com> In-Reply-To: <516D1A72.4040901@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <38F5CA705E572E478B1AB30E07509A74@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Is anyone else noticing issues with meeting minutes? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:06:35 -0000 On Apr 16, 2013, at 5:31 AM, Henrik Levkowetz wrote: > Fixed. The wg pages on tools.ietf.org should be updated within an hour > or so. Thanks! From elwynd@dial.pipex.com Sat Apr 20 15:44:07 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4B21F84B7 for ; Sat, 20 Apr 2013 15:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90NEU+uDdJ6t for ; Sat, 20 Apr 2013 15:44:06 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id E62B221F84B6 for ; Sat, 20 Apr 2013 15:44:05 -0700 (PDT) X-Trace: 718675347/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$OFF_NET_AUTH_ACCEPTED/None/81.187.254.249/None/elwynd@dial.pipex.com X-SBRS: None X-RemoteIP: 81.187.254.249 X-IP-MAIL-FROM: elwynd@dial.pipex.com X-SMTP-AUTH: elwynd@dial.pipex.com X-Originating-Country: GB/UNITED KINGDOM X-MUA: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAHUZc1FRu/75/2dsb2JhbABQg3DBboNSQD0WGAMCAQIBSw0IAQGIFJp1oEGTDQOXFYV4iyCDDQ X-IronPort-AV: E=Sophos;i="4.87,517,1363132800"; d="scan'208";a="718675347" X-IP-Direction: OUT Received: from weee-pc2.folly.org.uk (HELO [81.187.254.249]) ([81.187.254.249]) by smtp.pipex.tiscali.co.uk with ESMTP; 20 Apr 2013 23:43:58 +0100 Message-ID: <51731A2A.7040200@dial.pipex.com> Date: Sat, 20 Apr 2013 23:43:54 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF tools Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Tools-discuss] Managed to break rfcdiff? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 22:44:08 -0000 Hi. I was trying to generate a diff between RFC3530 and draft-ietf-nfs-rfc3530bis-25 just now but keep getting an empty page back (tried on more than one machine). I also tried a diff between -00 and -25 in the tracker with the same result. I believe this worked about 2 weeks ago but it is a very large diff Regards, Elwyn From dwing@cisco.com Sun Apr 21 21:12:28 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4254E21F8928 for ; Sun, 21 Apr 2013 21:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KYsaJTHE6fp for ; Sun, 21 Apr 2013 21:12:27 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7C21F87D0 for ; Sun, 21 Apr 2013 21:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=804; q=dns/txt; s=iport; t=1366603947; x=1367813547; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UbXEheALT6j9SlkX+SntYCt5aSbHWKU0Cbo0tF7t36U=; b=X2EkbbLafsPiJzsH3mjFlMPG9Qwn9PEm0xYho6n1I8Ga55bHm26MLQi/ cHuSPaFY9NaedcyrJ02bqVOgIZz/PHEzT3PHGJoGWWCNnG/H6T23cocz/ POxJFvjGrE73MIL5dGOULOdK9keqD85peMAMNnycJF4C90kOPge30tsIL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAEG4dFGrRDoG/2dsb2JhbABPgwY2AYJpsTSMYYEDFnSCHwEBAQMBAQEBNzQLBQsLRicwBhOIDgUNuw2PDDMHgmZhA4kNjgiBI4Roiw+DLBw X-IronPort-AV: E=Sophos;i="4.87,523,1363132800"; d="scan'208";a="79204188" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 22 Apr 2013 04:12:12 +0000 Received: from [10.32.240.195] ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3M4CBJq003230; Mon, 22 Apr 2013 04:12:11 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <51731A2A.7040200@dial.pipex.com> Date: Sun, 21 Apr 2013 21:12:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9397976E-66FB-4F45-8A9F-A20BC52069F5@cisco.com> References: <51731A2A.7040200@dial.pipex.com> To: Elwyn Davies X-Mailer: Apple Mail (2.1503) Cc: IETF tools Subject: Re: [Tools-discuss] Managed to break rfcdiff? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 04:12:28 -0000 On Apr 20, 2013, at 3:43 PM, Elwyn Davies wrote: > Hi. >=20 > I was trying to generate a diff between RFC3530 and = draft-ietf-nfs-rfc3530bis-25 just now but keep getting an empty page = back > (tried on more than one machine). > I also tried a diff between -00 and -25 in the tracker with the same = result. >=20 > I believe this worked about 2 weeks ago but it is a very large diff Working for me. Perhaps the problem is the filename you used is wrong = ("nfsv4"), = http://tools.ietf.org/rfcdiff?url1=3Drfc3530&url2=3Ddraft-ietf-nfsv4-rfc35= 30bis-25.txt -d >=20 > Regards, > Elwyn > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From Rolf.Winter@neclab.eu Mon Apr 22 01:34:17 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3909021F87B7 for ; Mon, 22 Apr 2013 01:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTWrFhFFwqwk for ; Mon, 22 Apr 2013 01:34:16 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4121F8200 for ; Mon, 22 Apr 2013 01:34:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E95DD103D6D for ; Mon, 22 Apr 2013 10:34:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1EodXzwJPx9 for ; Mon, 22 Apr 2013 10:34:15 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C94EF103D6C for ; Mon, 22 Apr 2013 10:34:10 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.174]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 22 Apr 2013 10:33:42 +0200 From: Rolf Winter To: "tools-discuss@ietf.org" Thread-Topic: small error - draft submission Thread-Index: Ac4/NBe/a13Msms6QkmvNBujiODQWw== Date: Mon, 22 Apr 2013 08:33:42 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D5562D923@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Tools-discuss] small error - draft submission X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 08:34:17 -0000 Hi, I have just submitted a new version of a draft (draft-ietf-mpls-tp-mip-mep-= map-07). The auto-post Email that goes out reaches me however it reports th= at a different author has submitted the draft. In other words it doesn't af= fect the submission process itself. It might just be a cosmetic thing unles= s this is also in a code section where you keep track about who does what o= r similar, then you might record wrong data. Best, Rolf=20 NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 From lars@netapp.com Tue Apr 23 17:37:51 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4537C21F96B1 for ; Tue, 23 Apr 2013 17:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.938 X-Spam-Level: X-Spam-Status: No, score=-9.938 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avrtStuLbaAV for ; Tue, 23 Apr 2013 17:37:48 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 836C921F9696 for ; Tue, 23 Apr 2013 17:37:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,538,1363158000"; d="scan'208";a="44153435" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 23 Apr 2013 17:37:48 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3O0bmlk015639 for ; Tue, 23 Apr 2013 17:37:48 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 23 Apr 2013 17:37:47 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Tue, 23 Apr 2013 17:37:47 -0700 From: "Eggert, Lars" To: "tools-discuss@ietf.org" Thread-Topic: "approve a draft" functionality for the IRTF? Thread-Index: AQHOQIPxX1F4ANXXFUyFSQjnnSWj+w== Date: Wed, 24 Apr 2013 00:37:47 +0000 Message-ID: <6781EB8F-559E-47CA-B13B-0E5164C9B04A@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F7280D8BEE5A54FBA06B9B2D4C705F2@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Tools-discuss] "approve a draft" functionality for the IRTF? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:37:51 -0000 Hi, is the IETF "approve a draft" functionality at https://datatracker.ietf.org= /submit/approvals/ supposed to be in effect for IRTF submissions as well? I'm asking, because I have recently seen draft-irtf-burleigh-bibe been post= ed, which - I guess - was supposed to be an individual submission targeted = at DTNRG, i.e., it should have been draft-burleigh-dtnrg-bibe-00. If the "approve a draft" function is not enabled for the IRTF, can it be tu= rned on? It would avoid situations like this. Thanks, Lars= From lars@netapp.com Tue Apr 23 17:40:17 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649F221F937D for ; Tue, 23 Apr 2013 17:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03PKOa7J9yHa for ; Tue, 23 Apr 2013 17:40:17 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id EB8BD21F937B for ; Tue, 23 Apr 2013 17:40:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,538,1363158000"; d="scan'208";a="44154167" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 23 Apr 2013 17:40:16 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3O0e9Xe002730 for ; Tue, 23 Apr 2013 17:40:16 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Tue, 23 Apr 2013 17:40:09 -0700 From: "Eggert, Lars" To: "tools-discuss@ietf.org Discussion" Thread-Topic: "approve a draft" functionality & WG advisors Thread-Index: AQHOQIRFMMTzeQ27BECvam5Uy4mpdA== Date: Wed, 24 Apr 2013 00:40:08 +0000 Message-ID: <17224071-37D7-4D09-8B79-290F7935D9A9@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <941152C2AE54174BB9F60CE773CCECA0@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Tools-discuss] "approve a draft" functionality & WG advisors X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:40:17 -0000 Hi, since I'm just looking at the "approve a draft" tool, here's another issue:= I'm technical advisor for the LWIG WG. I see that the tool actually lets m= e pre-approve LWIG WG documents.=20 I don't think that's supposed to be something that WG advisors can do. I ca= n see that it can be useful to allow this for WG secretaries, but not for t= ech advisors. Lars= From cabo@tzi.org Tue Apr 23 23:15:41 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D8921F8BDD for ; Tue, 23 Apr 2013 23:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.933 X-Spam-Level: X-Spam-Status: No, score=-106.933 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNHXnwnHKOrb for ; Tue, 23 Apr 2013 23:15:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0521F8B2B for ; Tue, 23 Apr 2013 23:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3O6FWZk009124; Wed, 24 Apr 2013 08:15:32 +0200 (CEST) Received: from [192.168.217.105] (p54891E67.dip0.t-ipconnect.de [84.137.30.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 50AC63AF6; Wed, 24 Apr 2013 08:15:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <17224071-37D7-4D09-8B79-290F7935D9A9@netapp.com> Date: Wed, 24 Apr 2013 08:15:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43FE3E27-3317-4B50-860C-03980EEF04F6@tzi.org> References: <17224071-37D7-4D09-8B79-290F7935D9A9@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1503) Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] "approve a draft" functionality & WG advisors X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 06:15:41 -0000 On Apr 24, 2013, at 02:40, "Eggert, Lars" wrote: > Hi, >=20 > since I'm just looking at the "approve a draft" tool, here's another = issue: I'm technical advisor for the LWIG WG. I see that the tool = actually lets me pre-approve LWIG WG documents.=20 >=20 > I don't think that's supposed to be something that WG advisors can do. = I can see that it can be useful to allow this for WG secretaries, but = not for tech advisors. While this is probably indeed a bug, I believe in general the tool = should err on the side of being a bit too lenient as opposed to = enforcing every single conceivable restriction. E.g., WG advisors may sometimes have a useful role in advising WG chairs = in process issues, and it may be expeditious to have them handle some = arcane process like this. They are rather unlikely to abuse such a capability. (Grace Hopper was right: It is easier to apologize than to obtain = permission.) Gr=FC=DFe, Carsten From rjsparks@nostrum.com Wed Apr 24 08:31:53 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE021F8FEB for ; Wed, 24 Apr 2013 08:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYux3-RdpgiG for ; Wed, 24 Apr 2013 08:31:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9221F8629 for ; Wed, 24 Apr 2013 08:31:52 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3OFVlfH087117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 24 Apr 2013 10:31:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5177FAE5.30603@nostrum.com> Date: Wed, 24 Apr 2013 10:31:49 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <6781EB8F-559E-47CA-B13B-0E5164C9B04A@netapp.com> In-Reply-To: <6781EB8F-559E-47CA-B13B-0E5164C9B04A@netapp.com> Content-Type: multipart/alternative; boundary="------------040001070508010400010101" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [Tools-discuss] "approve a draft" functionality for the IRTF? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:31:53 -0000 This is a multi-part message in MIME format. --------------040001070508010400010101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/23/13 7:37 PM, Eggert, Lars wrote: > Hi, > > is the IETF "approve a draft" functionality at https://datatracker.ietf.org/submit/approvals/ supposed to be in effect for IRTF submissions as well? > > I'm asking, because I have recently seen draft-irtf-burleigh-bibe been posted, which - I guess - was supposed to be an individual submission targeted at DTNRG, i.e., it should have been draft-burleigh-dtnrg-bibe-00. > > If the "approve a draft" function is not enabled for the IRTF, can it be turned on? It would avoid situations like this. No, it wouldn't have. That draft must have been manually posted? The online submission tool would not have accepted it since there is no group "burleigh". (From my test instance when trying to post draft-irtf-burleigh-bibe2-00, I get ---- Please correct the errors below. There is no active group with acronym 'burleigh', please rename your draft ---- However, I was able to post draft-irtf-dtnrg-burleigh-bibe2-00 to my test instance with no apparent check for -00 approval. I'll enter a ticket to add that functionality. RjS > > Thanks, > Lars > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss --------------040001070508010400010101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/23/13 7:37 PM, Eggert, Lars wrote:
Hi,

is the IETF "approve a draft" functionality at https://datatracker.ietf.org/submit/approvals/ supposed to be in effect for IRTF submissions as well?

I'm asking, because I have recently seen draft-irtf-burleigh-bibe been posted, which - I guess - was supposed to be an individual submission targeted at DTNRG, i.e., it should have been draft-burleigh-dtnrg-bibe-00.

If the "approve a draft" function is not enabled for the IRTF, can it be turned on? It would avoid situations like this.
No, it wouldn't have.

That draft must have been manually posted?
The online submission tool would not have accepted it since there is no group "burleigh".
(From my test instance when trying to post draft-irtf-burleigh-bibe2-00, I get
----
Please correct the errors below.

    There is no active group with acronym 'burleigh', please rename your draft
----

However, I was able to post draft-irtf-dtnrg-burleigh-bibe2-00 to my test instance with no apparent check for -00 approval.
I'll enter a ticket to add that functionality.

RjS




Thanks,
Lars
_______________________________________________
Tools-discuss mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

--------------040001070508010400010101-- From yaronf.ietf@gmail.com Thu Apr 25 06:20:51 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E60521F9406 for ; Thu, 25 Apr 2013 06:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9mWxuo1hLCt for ; Thu, 25 Apr 2013 06:20:50 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5862D21F95F0 for ; Thu, 25 Apr 2013 06:20:46 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id r16so1259205ead.41 for ; Thu, 25 Apr 2013 06:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=YLQjwO9kmdi9uGTlGxie1Uw0nRY57j91E5/ijg4qrRY=; b=LPJ27ffJ8M7zM7ZGkqsYlnLUpqU7b+IlP02EQO0VTmUZZ8KNSvLYF0Boz/7h8UpgQz XxZDmzPudqaHdVZge7BXp20GINV+UkTJ5r9F1Ni3e+jitnHcHF1K3+aA9vs+/yy3CMtv AaoTfwXEeWxuMn+wS+yBevBbWnYHcuO9gKDXIeutZOXdQ9fNiNWuew/gfLJPiPEFXvhl pJsgE10L1daAoZIv6krzQrArP6h74SWRlDY7HyNNpKH14ffUWhsmrNj3livDID83BxC8 A7E2108/scy4zEXEzeYQdeerb/Nx37rNNFdTp4fKqbjYL4TESdcyeqlnrWY7vRidO8vw N5Tw== X-Received: by 10.15.22.76 with SMTP id e52mr76003974eeu.7.1366896044655; Thu, 25 Apr 2013 06:20:44 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPSA id n7sm10394167eeo.0.2013.04.25.06.20.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 06:20:43 -0700 (PDT) Message-ID: <51792DA5.3050806@gmail.com> Date: Thu, 25 Apr 2013 16:20:37 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: tools-discuss@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Tools-discuss] "Changed document writeup" in Datatracker X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 13:20:51 -0000 Hi,

unless I'm missing something, this indication in the document's history (and the RSS feed) seems to be useless, because there is no versioning of the shepherd's writeup, so no way to know what has changed.

Thanks,
    Yaron
From fred@cisco.com Thu Apr 25 15:09:22 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D20F21F9709; Thu, 25 Apr 2013 15:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq1jBDFD3SyO; Thu, 25 Apr 2013 15:09:22 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F121921F9708; Thu, 25 Apr 2013 15:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2992; q=dns/txt; s=iport; t=1366927761; x=1368137361; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EGLVCTNVS5Miv52c4j6BGILJgG/ElGFNTPCNfuunfyE=; b=LNWMJ4UYefrVLpiwNZLA+f9y//FTrULXkBEQK4AHZxUCj2RFoTozCKfZ vcIE219EaDjHfs0cQPMFUORStxSzE+1LjXpEspBKdWxwbVUyXJM4YrC0u qScHWo2uZoaKOvZAx7jNGXRj0aXS2EeXWRI+UquGEHA0F9CvIizOr7SYY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAGpeVGrRDoG/2dsb2JhbABHCoMGvmeBBBZ0gh8BAQEDATo/BQsLOwtXBhMUBYd1Bb5PigKDdxR1MwcWgldhA4kRjguRIoFYgVYc X-IronPort-AV: E=Sophos;i="4.87,553,1363132800"; d="scan'208";a="76537596" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Apr 2013 22:09:20 +0000 Received: from sjc-fred-88110.cisco.com (sjc-fred-88110.cisco.com [10.19.64.123]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3PM9JkA027860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 22:09:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Fred Baker In-Reply-To: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 15:09:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1503) Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:09:22 -0000 On Apr 12, 2013, at 2:57 PM, The IESG wrote: > Abstract >=20 >=20 > This document describes a simple process that allows authors of > Internet-Drafts to record the status of known implementations by > including an Implementation Status section. This will allow > reviewers and working groups to assign due consideration to = documents > that have the benefit of running code, by considering the running > code as evidence of valuable experimentation and feedback that has > made the implemented protocols more mature. >=20 > The process in this document is offered as an experiment. Authors = of > Internet-Drafts are encouraged to consider using the process for > their documents, and working groups are invited to think about > applying the process to all of their protocol specifications. The > authors of this document intend to collate experiences with this > experiment and to report them to the community. I have read the draft. I like the concept. It applies primarily to = protocols and procedures, as opposed to white papers. It, however, puts = emphasis on the experience behind the usefulness of a protocol or = procedure, which is good. BTW, once upon a time we required implementation reports for routing = protocols, which I thought was a good thing and am concerned about the = loss of in recent times. That resulted in the publication of sets like = RFCs 1245, 1246, and 1247, which told about the protocol, its = operational characteristics, and the testing it went through (and by = implication, the implementations done of it) on its way to RFC-dom. In 2013, I personally would accomplish this a little differently, = however. A section in an internet draft, which gets frozen when the = draft is published, is perhaps useful for the working group and IESG = review processes. On the other hand, it requires implementers to = communicate with the draft author and the draft author to update the = draft in response to their input, which can be a logistical mess. It = ceases being useful once the draft is published. If a new implementation = is done, there is no report. If and old one is abandoned, nobody knows. = It is dated information, potentially true at a point in time but largely = irrelevant two minutes later. I would think we want something associated with the data tracker page - = another web page, perhaps implemented as a wiki - that enables an = implementer to identify himself and indicate the current status of the = implementation. Ideally, that might be coupled with a ticket system in = which issues are raised and closed, and comments are discussed. Ideally, = this would continue into the life of an RFC, with implementations being = identified ("The protocol in RFC 12345 is implemented in Andy Systems = releases 22.70 and later") and associated with errata ("but we really = wish that the parameter FOO had been specified").= From yaronf.ietf@gmail.com Fri Apr 26 02:12:24 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D879021F986B; Fri, 26 Apr 2013 02:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbjNRZaGaAqC; Fri, 26 Apr 2013 02:12:23 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id D678A21F9878; Fri, 26 Apr 2013 02:12:22 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b57so1587374eek.6 for ; Fri, 26 Apr 2013 02:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aGWPQ+XZ54FVKOvsaAZ4COb7Il2mx6oH5/jYqPLVIJI=; b=w10Lx5fwRuF8dElTFQBMLAvDBJpDJKaCmTFwrlYr+Xjsrhr+2gPT7d6ky9t/o8ntSQ yu1Y/Y9YxPh9ZAC6NFoL2fip4zVcPslNeyqt+dUDDTQaWeIL8dbg+WqUuNdNeDPti5zy hLfnhWzwRUBTT/uFbg1GP0jJ0ESl0LhefaFvJhTDNdKQDGzvF2Qzq4jNER6RyI7D5Pg7 dAtvHAIj21ZH2KrCNijAm49XSXf9BAaF4c1YNyOD59AHAM5ePpOGnrxlMCOU+7GAOeAm ALOsg1BnfyqoXDJYPBVi9M+TpQza2MINghYAcK8eEDFewgb9LXuob8Nr9ySIYwD1bCMF 2NMQ== X-Received: by 10.14.109.131 with SMTP id s3mr40837187eeg.26.1366967542082; Fri, 26 Apr 2013 02:12:22 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-130-139.red.bezeqint.net. [79.183.130.139]) by mx.google.com with ESMTPSA id w51sm14832390eev.13.2013.04.26.02.12.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 02:12:21 -0700 (PDT) Message-ID: <517A44F2.9050009@gmail.com> Date: Fri, 26 Apr 2013 12:12:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fred Baker References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 09:12:25 -0000 Hi Fred, Thanks for your review. Responding to you, and to other similar comments on the list: The draft refers to two "styles" of documenting implementation: in-line in the Internet draft, and by a reference to (presumably) a database or a wiki. The draft is also quite clear that the Implementation Status section should be removed from the I-D before publication. We do not specify what happens with Implementation wikis that are referenced by the I-D, presumably in most cases they will be abandoned. The in-line style is obviously simpler to set up (no infrastructure is needed) and in fact, this was the path taken by the 4 I-Ds that are using this option to date. There are two problems with long-term maintenance of implementation data: - The technical infrastructure (wiki, registration, etc.) should be set up. This is not too difficult, and there are lots of people who'd be happy to implement such a thing. - There should be long-term commitment to maintain the data. I think we simply don't have such processes in place, and personally I don't want to even try to deal with this problem. I suspect that we'd have to eventually use paid help if we are serious about keeping the information current, and I don't even think it would be worth the cost. Thanks, Yaron On 2013-04-26 01:09, Fred Baker wrote: > > On Apr 12, 2013, at 2:57 PM, The IESG wrote: > >> Abstract >> >> >> This document describes a simple process that allows authors of >> Internet-Drafts to record the status of known implementations by >> including an Implementation Status section. This will allow >> reviewers and working groups to assign due consideration to documents >> that have the benefit of running code, by considering the running >> code as evidence of valuable experimentation and feedback that has >> made the implemented protocols more mature. >> >> The process in this document is offered as an experiment. Authors of >> Internet-Drafts are encouraged to consider using the process for >> their documents, and working groups are invited to think about >> applying the process to all of their protocol specifications. The >> authors of this document intend to collate experiences with this >> experiment and to report them to the community. > > > I have read the draft. I like the concept. It applies primarily to protocols and procedures, as opposed to white papers. It, however, puts emphasis on the experience behind the usefulness of a protocol or procedure, which is good. > > BTW, once upon a time we required implementation reports for routing protocols, which I thought was a good thing and am concerned about the loss of in recent times. That resulted in the publication of sets like RFCs 1245, 1246, and 1247, which told about the protocol, its operational characteristics, and the testing it went through (and by implication, the implementations done of it) on its way to RFC-dom. > > In 2013, I personally would accomplish this a little differently, however. A section in an internet draft, which gets frozen when the draft is published, is perhaps useful for the working group and IESG review processes. On the other hand, it requires implementers to communicate with the draft author and the draft author to update the draft in response to their input, which can be a logistical mess. It ceases being useful once the draft is published. If a new implementation is done, there is no report. If and old one is abandoned, nobody knows. It is dated information, potentially true at a point in time but largely irrelevant two minutes later. > > I would think we want something associated with the data tracker page - another web page, perhaps implemented as a wiki - that enables an implementer to identify himself and indicate the current status of the implementation. Ideally, that might be coupled with a ticket system in which issues are raised and closed, and comments are discussed. Ideally, this would continue into the life of an RFC, with implementations being identified ("The protocol in RFC 12345 is implemented in Andy Systems releases 22.70 and later") and associated with errata ("but we really wish that the parameter FOO had been specified"). > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > From cabo@tzi.org Fri Apr 26 03:18:24 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6721F989F for ; Fri, 26 Apr 2013 03:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHFkwh7uPvD3 for ; Fri, 26 Apr 2013 03:18:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0A68021F989C for ; Fri, 26 Apr 2013 03:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3QAIGTP021528 for ; Fri, 26 Apr 2013 12:18:16 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F3463B81; Fri, 26 Apr 2013 12:18:16 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Apr 2013 12:18:15 +0200 To: "tools-discuss@ietf.org Discussion" Message-Id: <0FE055C8-AD6D-4355-98B2-0E874A0C16FB@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [Tools-discuss] idnits tool strangeness X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 10:18:24 -0000 Something is not right about the online idnits tools. =46rom a recent mail exchange: > I do not know why the nits check tool = http://www.ietf.org/tools/idnits/ reports so many problems. While I do = not understand many of them, for example: >=20 > /tmp/draft-ietf-lwig-terminology-04.txt(185): update_references( = [RFC6606] distinguishes "power-affluent" nodes (mains-powered or) This instance seems to work better: http://tools.ietf.org/tools/idnits/ Still, you have to ignore the barrage of "outdated state file" messages = at the start, though (see below). I'm using the homebrew idnits (just submitted a pull request there, = BTW), so I'm not directly concerned. But can we restore online idnits to its former greatness? Gr=FC=DFe, Carsten idnits 2.12.16=20 tmp/draft-ietf-lwig-terminology.txt: - The draft- state file is not from today. Attempting to download a newer one... - No draft-brandt-6man-lowpanz state file. Attempting to download it... - No draft-clausen-lln-rpl-experiences state file. Attempting to = download it... - No draft-hui-vasseur-roll-rpl-deployment state file. Attempting to = download it... - No draft-ietf-6lowpan-btle state file. Attempting to download it... - No draft-ietf-lwig-terminology state file. Attempting to download = it... - No draft-ietf-roll-terminology state file. Attempting to download = it... - No draft-mariager-6lowpan-v6over-dect-ule state file. Attempting to = download it... - No rfc0793 state file. Attempting to download it... Attempted to download rfc0793 state... Failure fetching the file, proceeding without it. - The rfc1024 state file is not from today. Attempting to download a newer one... - The rfc172 state file is not from today. Attempting to download a newer one... - The rfc1981 state file is not from today. Attempting to download a newer one... - No rfc218 state file. Attempting to download it... - No rfc250 state file. Attempting to download it... - No rfc284 state file. Attempting to download it... Attempted to download rfc284 state... Failure fetching the file, proceeding without it. - No rfc3149 state file. Attempting to download it... - The rfc421 state file is not from today. Attempting to download a newer one... - The rfc4838 state file is not from today. Attempting to download a newer one... - No rfc4919 state file. Attempting to download it... - No rfc6551 state file. Attempting to download it... - No rfc6606 state file. Attempting to download it... - The rfc793 state file is not from today. Attempting to download a newer one... - The rfc802 state file is not from today. Attempting to download a newer one... - No rfc9959 state file. Attempting to download it... Attempted to download rfc9959 state... Failure fetching the file, proceeding without it. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to = http://www.ietf.org/id-info/1id-guidelines.txt:= From fred@cisco.com Fri Apr 26 09:07:40 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B12E21F9A6E; Fri, 26 Apr 2013 09:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhlN2L-bq9H4; Fri, 26 Apr 2013 09:07:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10321F98B8; Fri, 26 Apr 2013 09:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=785; q=dns/txt; s=iport; t=1366992459; x=1368202059; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YRe2hPBddYib1WmjP5BXKWMFpk2YxYYil2wO5xaAj+g=; b=RbiGeRBVZOlfEDIN6PxAE/yzU6F2oTGhJoIPRT5EWkrkGljRT19DgooX FoIcbJR4dLbMy7T/ZzVqau0A+9puZTUz9TOADisJaMrFQi7jqa0IDZQK5 1Oq5zXi0R8yTWJqQ87y7UCGiLPU6BLn9LG7XwHzEvg5CFBucA559A5A/x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAOCkelGtJXG+/2dsb2JhbABRgweDJrtJgQMWdIIgAQEEOj8QAgEIIhQFCyERJQIEDgUIh3oDD7ZGDYhNjDyCIwIxB4JtYQOVOY1uhR+BWIE2gig X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="203526911" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 26 Apr 2013 16:07:39 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3QG7cvH032031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 16:07:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 11:07:38 -0500 From: "Fred Baker (fred)" To: Yaron Sheffer Thread-Topic: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC Thread-Index: AQHOQl4w9qDGEiWEcESvIj5fcta465jo/2gA Date: Fri, 26 Apr 2013 16:07:37 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517A44F2.9050009@gmail.com> In-Reply-To: <517A44F2.9050009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E4999E69B65BA43990776CD4F0FAB7B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:07:40 -0000 On Apr 26, 2013, at 2:12 AM, Yaron Sheffer wrote: > - There should be long-term commitment to maintain the data. I think we s= imply don't have such processes in place, and personally I don't want to ev= en try to deal with this problem. I suspect that we'd have to eventually us= e paid help if we are serious about keeping the information current, and I = don't even think it would be worth the cost. Understood. That said, we already have working group wikis and errata. I do= n't want to trivialize the investment, but it seems like we have at least p= art of the infrastructure already. I'm asking what will be the best for IET= F discussion and for maintenance of the information. I suspect it's somethi= ng we can do if we choose to.= From dhc@dcrocker.net Fri Apr 26 09:16:44 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8C21F9838; Fri, 26 Apr 2013 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvJwlkaU0qbp; Fri, 26 Apr 2013 09:16:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3721F9831; Fri, 26 Apr 2013 09:16:43 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3QGGdA4004658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 09:16:42 -0700 Message-ID: <517AA859.9060804@dcrocker.net> Date: Fri, 26 Apr 2013 09:16:25 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "ietf@ietf.org" References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 26 Apr 2013 09:16:43 -0700 (PDT) Cc: IESG , Tools Team Discussion , draft-sheffer-running-code@tools.ietf.org Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:16:45 -0000 Given this thread on the ietf list, I guess I should forward the following, which was done as a solicited Apps Area review for this draft: -------- Original Message -------- Subject: Review of: draft-sheffer-running-code Date: Wed, 24 Apr 2013 06:38:24 -0700 From: Dave Crocker To: draft-sheffer-running-code.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Review ------ Title: Improving Awareness of Running Code: the Implementation Status Section I-D: draft-sheffer-running-code-04 Reviewer: D. Crocker Review Date: 24 April 2013 Summary: Given an organizational motto of "Rough consensus and running code", implementation experience has a value built into the IETF's DNA. However formal IETF reliance on running code for specifications has been minimal, with its only universal occurrence being in consideration of advanced standards status; it is notably /not/ an organizational requirement for entry-level Proposed Standard status, if only for the very high barrier to publication this imposes on document versions that were intended to be preliminary. The current draft proposes an experiment to optionally include documentation of implementations as part of document development, prior to issuance of a specification as an RFC. Within the broader perspective of pre- and post-standardization efforts, it is quite common to document available implementations of a specification. (As a convenient example, see http://dkim.org/deploy.) In effect, the current proposal merely seeks to have a common IETF-based means of recording a type of information that industry has already frequently formulated. In their current form, the draft and the proposal seem likely to be useful. However, both could be improved. The draft includes some language and assertions that would benefit from being a bit more carefully written; questions, comments and suggestions are in the detailed comments below. The proposal itself would benefit from directly paying more attention to existing industry practice, which is implied by the "alternatives" section; that is, that implementation lists already happen and are maintained after IETF document processing. The proposal should do a better job of integrating this fact into its design. One approach could be a relatively simple document change, to distinguish between specifying the information to be reported, as distinct from the means of reporting it -- think of it as payload vs. mechanism... Specify them separately. Then define both how to incorporate the information directly and the form of an external citation to it; this would eliminate the document's section on 'alternatives' and treat the original and alternative methods as equal. d/ Detailed Comments: > 1. Introduction > > Most IETF participants are familiar with the saying, "rough > consensus and running code" [Tao], and can identify with its > pragmatic approach. However, there are many examples of > Internet-Drafts containing protocol specification that have gone > through to publication as Proposed Standard RFCs without > implementation. Some of them may never get implemented. The "however" implies that it is wrong or problematic for Proposed to be assigned to unimplemented protocols. It isn't. I suggest a softer tone, while still noting the relevantfact. Something like: It is not a requirement of Proposed Standard status to have any implementations; by the time of reaching that status, some specifications have been implemented and some have not. Indeed, some never get implemented. > Over time, a variety of policies have been implemented within the implemented -> applied > IETF to consider running code. In the Routing Area it used to be a > requirement that one or more implementations must exist before an > Internet-Draft could be published as a Proposed Standard RFC > [RFC1264]. That RFC was later obsoleted and the requirement for > implementation was lifted, but each working group was given the > authority to impose its own implementation requirements [RFC4794] > and at least one working group (IDR) continues to require two > independent implementations. > > The hypothesis behind this document is that there are benefits to > the this -> the current > IETF standardization process of producing implementations of > protocol specifications before publication as RFCs. These benefits, > which I suspect that that isn't its "hypothesis" at all, since the document does nothing to specify or directly affect policies for requiring or encouraging implementation. Perhaps there is a hope that the proposed notation about implementations will serve as some sort of encouragement, but that's pretty indirect; success or failure of the proposed experiment won't validate or invalidate whether there are benefits to early implementation. And providing for a notation convention hardly constitutes an 'incentive'. Rather, I believe the premise of the document is that the community is aided by /more widely knowing about/ early implementations. > include determining that the specification is comprehensible and > that there is sufficient interest to implement, are further discussed > in Section 4. > > This document describes a simple process that allows authors of process -> mechanism > Internet-Drafts to record the status of known implementations, by > including an Implementation Status section. The document defines > (quite informally) the contents of this section, to ensure that the > relevant information is included. This will allow reviewers and > working groups to assign due consideration to documents that have > the benefit of running code, by considering the running code as > evidence of valuable experimentation and feedback that has made the > implemented protocols more mature. The above last sentence seems to be the actual claimed value proposition for the experiment. > This document provides a mechanism to record and publicize the This sentence seems entirely redundant. > existence of running code. It is up to the individual working > groups to use this information as they see fit, but one result might > be the preferential treatment of documents resulting in them being > processed more rapidly. I think it won't be the working group that 'uses' the information, but rather IETF management and the broader community? > The process in this document is offered as an experiment. Authors > of Internet-Drafts are encouraged to consider using the process for > their documents, and working groups are invited to think about > applying the process to all of their protocol specifications. > > The scope of the intended experiment is all Internet-Drafts whether Probably not all I-Ds, since they do not all contain implementable specifications. > > > Sheffer & Farrel Expires October 14, 2013 [Page > 3] Internet-Draft Running Code > April 2013 > > > produced within IETF working groups, outside working groups but What I-Ds are produced by "outside working groups"? I can't tell who this refers to.It's probably just as well to remove the attempted case analysis for groups and just say that the scope is all specifications issued as I-Ds. > intended for IETF consensus, or for publication on the Independent > Stream. However, it is expected that most benefit from the that most benefit from the experiment will -> the greatest benefit in the experiment will > experiment will be seen with Standards Track documents developed > within working groups. Here's my guess: 1. Those offering comments or making decisions about the status of document will be aided by this added information. 2. Those deciding about whether to write code or deploy it will be aided. I think the latter is likely to be the greater benefit. > The authors of this document intend to collate experiences with this > experiment and to report them to the community. > > > 2. The "Implementation Status" Section > > Each Internet-Draft may contain a section entitled "Implementation > Status". This section, if it appears, should be located just before > the "Security Considerations" section and contain, for each existing > implementation: > > o The implementation's name and/or a link to a web page describing > the implementation. o A brief general description. o The > implementation's level of maturity: research, prototype, alpha, beta, > production, widely used etc. o Coverage: which parts of the protocol > specification are implemented and which versions of the > Internet-Draft were implemented. o Licensing: the terms under which > the implementation can be used. For example: proprietary, royalty > licensing, freely distributable with acknowledgement (BSD style), > freely distributable with requirement to redistribute source (GPL > style), other (specify). o Contact information: ideally a person's > name and email address, but possibly just a URL or mailing list. List the organization that did the implementation and contact information for the proper place in the organization. > In addition, this section can contain information about the > interoperability of any or all of the implementations. > > Since this information is necessarily time-dependent, it is > inappropriate for inclusion in a published RFC. The authors should Way to bury the lead. This stuff won't be in the published document? It's only for pre-publication? > include a note to the RFC Editor requesting that the section be > removed before publication. > > 2.1. Introductory Text > > The following boilerplate text is proposed to head the > Implementation Status section: > > > > > > > > Sheffer & Farrel Expires October 14, 2013 [Page > 4] Internet-Draft Running Code > April 2013 > > > This section records the status of known implementations of the > protocol defined by this specification at the time of posting of this > Internet-Draft, and is based on a proposal described in [RFC Editor: > replace by a reference to this document]. According to [RFC Editor: > replace by a reference to this document], "this will allow reviewers > and working groups to assign due consideration to documents that have > the benefit of running code, by considering the running code as > evidence of valuable experimentation and feedback that has made the > implemented protocols more mature. It is up to the individual > working groups to use this information as they see fit". > > Authors are requested to add a note to the RFC Editor at the top of > this section, advising the Editor to remove the entire section > before publication, as well as the reference to [RFC Editor: replace > by a reference to this document]. > > > 3. Alternative Formats Yes! > Sometimes it can be advantageous to publish the implementation > status separately from the base Internet-Draft, e.g. on the IETF > wiki: > > o When the Implementation Status section becomes too large to be > conveniently managed within the document. o When a working group > decides to have implementors, rather than authors, keep the status of > their implementations current. o When a working group already > maintains an active wiki and prefers to use it for this purpose. > > It is highly desirable for all readers of the Internet-Draft to be > made aware of this information. Initially this can be done by > replacing the Implementation Status section's contents with a URL > pointing to the wiki. Later, the IETF Tools may support this > functionality, e.g. by including such a link from the HTMLized draft > version, similar to the IPR link. > > If the implementation status is published separately from the I-D, > then this information needs to be openly available without requiring > authentication, registration or access controls if it is to have any > useful effects. > > > 4. Benefits > > Publishing the information about implementations provides the > working group with several benefits: > > > > > Sheffer & Farrel Expires October 14, 2013 [Page > 5] Internet-Draft Running Code > April 2013 > > > o Participants are motivated to implement protocol proposals, which > helps in discovering protocol flaws at an early stage. The psychological premise seems to be that getting cited in this list will somehow serve as an incentive to implementers. I can imagine that they'll like being listed, but find it extremely difficult to believe that it will affect whether they do the work; not that I think it's a deciding factor, but note that the ego value is further reduced by the information's being ephemeral, since it it removed prior to RFC publication! > o Other participants can use the software, to evaluate the > usefulness of protocol features, its correctness (to some degree) and > other properties, such as resilience and scalability. Efficacy of the spec. > o WG members may choose to perform interoperability testing with > known implementations, especially when they are publicly available. Interoperability of the spec. > o In the case of open source, people may want to study the code to > better understand the protocol and its limitations, determine if the > implementation matches the protocol specification, and whether the > protocol specification has omissions or ambiguities. Reference implementation as exemplar. > o Working group chairs and ADs may use the information provided to > help prioritize the progress of I-Ds in some way. What does "prioritize the progress" mean? > o Similarly, the information is useful when deciding whether the > document should be progressed on a different track (individual > submission, Experimental etc.). Assess spec maturity. (This seems redundant with the combination of Efficacy and Interoperability?) > o And lastly, some protocol features may be hard to understand, and > for such features, the mere assurance that they can be implemented is > beneficial. mumble. Might highlight problems with the spec language. Might undermine the spec text by causing code to be used in place of it? > We do not specify here whether and to what degree working groups are > expected to prefer proposals that have "running code" associated > with them, over others that do not. > > > 5. Process Experiment > > The current proposal is proposed as an experiment. The inclusion of > "Implementation Status" sections in Internet-Drafts is not > mandatory, but the authors of this document wish to encourage authors > of other Internet-Drafts to try out this simple process to discover > whether it is useful. Working group chairs are invited to suggest > this process to document editors in their working groups, and to draw > the attention of their working group participants to "Implementation > Status" sections where they exist. > > Following a community discussion, it was concluded that [RFC3933] is > not an appropriate framework for this experiment, primarily because > no change is required to any existing process. It defines a document meta-data encoding mechanism. That's not really a "process". > 7. Security Considerations > > This is a process document and therefore, it does not have a direct > effect on the security of any particular IETF protocol. Better Better -> However, better d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From bob.hinden@gmail.com Fri Apr 26 09:50:00 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA821F9A24 for ; Fri, 26 Apr 2013 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O7Hp38Ns0SY for ; Fri, 26 Apr 2013 09:49:59 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B29E121F9A23 for ; Fri, 26 Apr 2013 09:49:59 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id q13so2746636vbe.16 for ; Fri, 26 Apr 2013 09:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6ApUdN7O7cQMVRrbL4MYnPcCMPvefjsxQxf3V/qZ7Jc=; b=rKipJrePzoQhhTn9GGBFNziTwDD00faaF0Pn5j8KdLeRuPwvvn2n9zRGTO2WhTuGKl Ze8cXdhZ2XkmdeSBxKbwZTrIR1Ucdi2FHnOZb9NQwIzAtE8coFpF0FHRV0t4HG/1jwG1 GrnDOLrQaUOLn//yIC39St9OANRktB4M27BnORsWNHE0CndCEdsa2zoGRuliK1u3p43p 6SazKz82R2bm9vNossNykQoCHAkSd9rDMiqrYfVRb9+ZcaWg7z7WX4mQh1eJdWr3nsuB nXXL5ihc/nLW2oyrRMTS+oZAS9NBxI+r3j6nM9x7FqDWmyGckHAPeRlHkZIrxKzRcjfE F3Nw== X-Received: by 10.52.186.69 with SMTP id fi5mr24896771vdc.105.1366994999201; Fri, 26 Apr 2013 09:49:59 -0700 (PDT) Received: from [10.0.0.35] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPSA id a17sm3386668vdj.2.2013.04.26.09.49.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 09:49:54 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Bob Hinden In-Reply-To: <0FE055C8-AD6D-4355-98B2-0E874A0C16FB@tzi.org> Date: Fri, 26 Apr 2013 09:49:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B529406-06BB-4F3A-A4FE-C37CF954D8CE@gmail.com> References: <0FE055C8-AD6D-4355-98B2-0E874A0C16FB@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] idnits tool strangeness X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:50:00 -0000 I have seen something similar to this, but never got around to reporting = it. I usually run it again and it goes away. Bob On Apr 26, 2013, at 3:18 AM, Carsten Bormann wrote: > Something is not right about the online idnits tools. >=20 > =46rom a recent mail exchange: >=20 >> I do not know why the nits check tool = http://www.ietf.org/tools/idnits/ reports so many problems. While I do = not understand many of them, for example: >>=20 >> /tmp/draft-ietf-lwig-terminology-04.txt(185): update_references( = [RFC6606] distinguishes "power-affluent" nodes (mains-powered or) >=20 > This instance seems to work better: >=20 > http://tools.ietf.org/tools/idnits/ >=20 > Still, you have to ignore the barrage of "outdated state file" = messages at the start, though (see below). >=20 > I'm using the homebrew idnits (just submitted a pull request there, = BTW), so I'm not directly concerned. > But can we restore online idnits to its former greatness? >=20 > Gr=FC=DFe, Carsten >=20 >=20 > idnits 2.12.16=20 >=20 > tmp/draft-ietf-lwig-terminology.txt: > - The draft- state file is not from today. > Attempting to download a newer one... > - No draft-brandt-6man-lowpanz state file. Attempting to download = it... > - No draft-clausen-lln-rpl-experiences state file. Attempting to = download it... > - No draft-hui-vasseur-roll-rpl-deployment state file. Attempting to = download it... > - No draft-ietf-6lowpan-btle state file. Attempting to download it... > - No draft-ietf-lwig-terminology state file. Attempting to download = it... > - No draft-ietf-roll-terminology state file. Attempting to download = it... > - No draft-mariager-6lowpan-v6over-dect-ule state file. Attempting to = download it... > - No rfc0793 state file. Attempting to download it... > Attempted to download rfc0793 state... > Failure fetching the file, proceeding without it. > - The rfc1024 state file is not from today. > Attempting to download a newer one... > - The rfc172 state file is not from today. > Attempting to download a newer one... > - The rfc1981 state file is not from today. > Attempting to download a newer one... > - No rfc218 state file. Attempting to download it... > - No rfc250 state file. Attempting to download it... > - No rfc284 state file. Attempting to download it... > Attempted to download rfc284 state... > Failure fetching the file, proceeding without it. > - No rfc3149 state file. Attempting to download it... > - The rfc421 state file is not from today. > Attempting to download a newer one... > - The rfc4838 state file is not from today. > Attempting to download a newer one... > - No rfc4919 state file. Attempting to download it... > - No rfc6551 state file. Attempting to download it... > - No rfc6606 state file. Attempting to download it... > - The rfc793 state file is not from today. > Attempting to download a newer one... > - The rfc802 state file is not from today. > Attempting to download a newer one... > - No rfc9959 state file. Attempting to download it... > Attempted to download rfc9959 state... > Failure fetching the file, proceeding without it. >=20 > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > = --------------------------------------------------------------------------= -- >=20 > No issues found here. >=20 > Checking nits according to = http://www.ietf.org/id-info/1id-guidelines.txt: > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From hammondjohnson@hushmail.com Sat Apr 27 14:57:08 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B821F9939 for ; Sat, 27 Apr 2013 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IYsmX9S2QDy for ; Sat, 27 Apr 2013 14:57:08 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7684521F991F for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 794ECE7C62 for ; Sat, 27 Apr 2013 17:52:44 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:52:44 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 30A69E6736; Sat, 27 Apr 2013 17:52:44 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:52:44 -0400 To: tools-discuss@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175244.30A69E6736@smtp.hushmail.com> Subject: [Tools-discuss] Biggest Fake Conference in Computer Science X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:08 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From adrian@olddog.co.uk Sun Apr 28 04:22:15 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA221F99D2; Sun, 28 Apr 2013 04:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4138AhzrO+F; Sun, 28 Apr 2013 04:22:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CBDF421F9965; Sun, 28 Apr 2013 04:22:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SBMA1K015263; Sun, 28 Apr 2013 12:22:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SBM8AN015247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Apr 2013 12:22:09 +0100 From: "Adrian Farrel" To: "'Fred Baker \(fred\)'" , "'Yaron Sheffer'" References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517A44F2.9050009@gmail.com> <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> Date: Sun, 28 Apr 2013 12:22:08 +0100 Message-ID: <014001ce4402$9fa4e3d0$deeeab70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQI+/nXAKV+Un4kRrUVd9ZCgs2LIxwID6x0NAQwM5vIBJAljXpfoZmGQ Cc: ietf@ietf.org, tools-discuss@ietf.org Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 11:22:15 -0000 Hi Fred, I'm in complete agreement with you, but... :-) Before investing in a common set of tools to archive implementation information, I wanted to see whether there was *any* intention to make that information available. Thus, this is a baby-step towards the end result that you and I wold like to see. If, after our 18 month experiment, it turns out that no-one wants to record implementation information, we will know where we stand (or sit). OTOH, if there is good support for the idea, we can move to the next stage. Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Fred > Baker (fred) > Sent: 26 April 2013 17:08 > To: Yaron Sheffer > Cc: ; tools-discuss@ietf.org Discussion > Subject: Re: [Tools-discuss] Last Call: > (Improving Awareness of Running Code: the Implementation Status Section) to > Experimental RFC > > > On Apr 26, 2013, at 2:12 AM, Yaron Sheffer > wrote: > > > - There should be long-term commitment to maintain the data. I think we > simply don't have such processes in place, and personally I don't want to even try > to deal with this problem. I suspect that we'd have to eventually use paid help if > we are serious about keeping the information current, and I don't even think it > would be worth the cost. > > Understood. That said, we already have working group wikis and errata. I don't > want to trivialize the investment, but it seems like we have at least part of the > infrastructure already. I'm asking what will be the best for IETF discussion and for > maintenance of the information. I suspect it's something we can do if we choose > to.= From adrian@olddog.co.uk Sun Apr 28 04:22:15 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F8921F99D5; Sun, 28 Apr 2013 04:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iwOUXYJYevL; Sun, 28 Apr 2013 04:22:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CE5D221F99CB; Sun, 28 Apr 2013 04:22:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SBM9IW015258; Sun, 28 Apr 2013 12:22:09 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3SBM8AM015247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Apr 2013 12:22:09 +0100 From: "Adrian Farrel" To: "'John C Klensin'" , "'Fred Baker \(fred\)'" , "'Yaron Sheffer'" References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517A44F2.9050009@gmail.com> <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> <0E1D18E70456E3EEE8A2BEC0@JcK-HP8200.jck.com> In-Reply-To: <0E1D18E70456E3EEE8A2BEC0@JcK-HP8200.jck.com> Date: Sun, 28 Apr 2013 12:22:08 +0100 Message-ID: <013f01ce4402$9f5a9460$de0fbd20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQI+/nXAKV+Un4kRrUVd9ZCgs2LIxwID6x0NAQwM5vIBJAljXgJx6SBNl9TYUZA= Cc: ietf@ietf.org, tools-discuss@ietf.org Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 11:22:16 -0000 Hi John, Seems consistent with what is in the I-D at the moment. See section 3. Thus, those who want to record the info in the I-D can do that, while those who want to go straight to a wiki can do that (although we ask that the I-D has a pointer to the wiki). Cheers, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of John C > Klensin > Sent: 26 April 2013 17:51 > To: Fred Baker (fred); Yaron Sheffer > Cc: ; tools-discuss@ietf.org Discussion > Subject: Re: [Tools-discuss] Last Call: > (Improving Awareness of Running Code: the Implementation Status Section) to > Experimental RFC > > > > --On Friday, April 26, 2013 16:07 +0000 "Fred Baker (fred)" > wrote: > > > > > On Apr 26, 2013, at 2:12 AM, Yaron Sheffer > > wrote: > > > >> - There should be long-term commitment to maintain the data. > >> I think we simply don't have such processes in place, and > >> personally I don't want to even try to deal with this > >> problem. I suspect that we'd have to eventually use paid help > >> if we are serious about keeping the information current, and > >> I don't even think it would be worth the cost. > > > > Understood. That said, we already have working group wikis and > > errata. I don't want to trivialize the investment, but it > > seems like we have at least part of the infrastructure > > already. I'm asking what will be the best for IETF discussion > > and for maintenance of the information. I suspect it's > > something we can do if we choose to. > > Fred, > > First, I agree with both the above and with your prior note > agreeing with the general idea and suggesting something more > "live" than a section of an I-D. Second, while I certainly see > the value, I would get nervous if we were to move significantly > toward a long-term, IETF-supported, official statement or > compendium of implementation status. At least unless pursued > with great caution [1], such a thing would raise some of the > same issues that going into the conformance testing business > does in terms of the perception of guarantees that a given > implementation is somehow "IETF approved". > > Perhaps the right model would be to keep this material in I-Ds > (as the proposal suggests) to support the evolution and review > of specification documents, then to move it to a wiki or > equivalent that was clearly identified as unofficial and for the > convenience of the community and that was "maintained by the > IETF" only to the extent needed to minimize spam, libel, and > other nonsense. > > It also occurs to me that an alternative to part of the > experiment (still consistent with it, IMO) would be to start the > wiki process earlier and use the I-Ds merely to snapshot the > wiki at various points to help in the review process. That > would give both the advantages of a continually-evolving list > and those of periodic stable snapshots. > > Just a thought or two. > > john > > > > [1] Images of dragging along as small pack of lawyers, > albatross-like, are probably in order. From yaronf.ietf@gmail.com Sun Apr 28 08:04:02 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16521F9387; Sun, 28 Apr 2013 08:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF7W89Hw94ff; Sun, 28 Apr 2013 08:04:01 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 134E021F9851; Sun, 28 Apr 2013 08:03:59 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so3006302wgh.3 for ; Sun, 28 Apr 2013 08:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f4sA2JhBGbEEibjVVubCwY2GcoDTiVsr9qkzMabMZig=; b=diIqM1UFdO1w3fqJOMljMjnuQYVnqIk2jgX57sjNQnQOD2aZYhg0g/0ZKtvWcpRIur OY+l8dRpscnk18sQTjUHJPdBi/r20H49nGObAnugVYqWa44kq8Re/x5Ly0zbeCUU6+0t 5c3nREDeNnhNBAdU8r3AwJezRVukjv0hvJVAJPw837ZrSlkhvNP9dAl0pUv2mXPag2HY fobXwBkih1WU8ht5nQ0GnJiywj1ZdFLy1MWW/D8igaMIVM11KN0/PHdxvOpdm9EQuKQ7 BlSxWLPfXE+A1gGgkGqV6Mh010f+9vHO1OVZ1g8eiHutnvEdHVRXBCWBUOf6B5pMkSm2 68yA== X-Received: by 10.194.108.165 with SMTP id hl5mr41127617wjb.22.1367161439261; Sun, 28 Apr 2013 08:03:59 -0700 (PDT) Received: from [10.0.0.23] (bzq-79-177-180-167.red.bezeqint.net. [79.177.180.167]) by mx.google.com with ESMTPSA id q20sm16284450wiv.7.2013.04.28.08.03.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 08:03:58 -0700 (PDT) Message-ID: <517D3A5C.4070009@gmail.com> Date: Sun, 28 Apr 2013 18:03:56 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dave Crocker References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517AA859.9060804@dcrocker.net> In-Reply-To: <517AA859.9060804@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-sheffer-running-code@tools.ietf.org, "ietf@ietf.org" , Tools Team Discussion , IESG Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 15:04:02 -0000 Hi Dave, Thank you for your thorough review. While I accept many of your comments, I must say I disagree with you on a few points, which together go to the core of our motivation in writing this document. Thank you for helping me clarify these points to myself :-) - Our goal is much *less* ambitious than defining a framework for documenting implementations for long-term protocol projects. Our primary goal is to aid working group members in making informed decisions about the quality of specifications. I believe this narrow focus is much more realistic. - As a result of the above: 1. We define the information as pre-RFC only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS (although we see them as valid alternatives); 3. We focus on WG documents, as opposed to "all" IETF documents. - Despite the glowing counterexample of DKIM, it is rarely practical to maintain implementation status information, keeping it current for years (put bluntly, you need to pay someone to do that). The IETF certainly does not have the processes or mechanisms to do so. And we do not try to establish such processes here. Please see my detailed comments below. Thanks, Yaron On 2013-04-26 19:16, Dave Crocker wrote: > Given this thread on the ietf list, I guess I should forward the > following, which was done as a solicited Apps Area review for this draft: > > > -------- Original Message -------- > Subject: Review of: draft-sheffer-running-code > Date: Wed, 24 Apr 2013 06:38:24 -0700 > From: Dave Crocker > To: draft-sheffer-running-code.all@tools.ietf.org, > apps-discuss@ietf.org, iesg@ietf.org > > Howdy. > > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > > Review > ------ > > > Title: Improving Awareness of Running Code: the Implementation Status > Section > > I-D: draft-sheffer-running-code-04 > > Reviewer: D. Crocker > Review Date: 24 April 2013 > > > Summary: > > Given an organizational motto of "Rough consensus and running code", > implementation experience has a value built into the IETF's DNA. > However formal IETF reliance on running code for specifications has been > minimal, with its only universal occurrence being in consideration of > advanced standards status; it is notably /not/ an organizational > requirement for entry-level Proposed Standard status, if only for the > very high barrier to publication this imposes on document versions that > were intended to be preliminary. The current draft proposes an > experiment to optionally include documentation of implementations as > part of document development, prior to issuance of a specification as an > RFC. > > Within the broader perspective of pre- and post-standardization efforts, > it is quite common to document available implementations of a > specification. (As a convenient example, see http://dkim.org/deploy.) > In effect, the current proposal merely seeks to have a common IETF-based > means of recording a type of information that industry has already > frequently formulated. > > In their current form, the draft and the proposal seem likely to be > useful. However, both could be improved. > > The draft includes some language and assertions that would benefit from > being a bit more carefully written; questions, comments and suggestions > are in the detailed comments below. > > The proposal itself would benefit from directly paying more attention to > existing industry practice, which is implied by the "alternatives" > section; that is, that implementation lists already happen and are > maintained after IETF document processing. The proposal should do a > better job of integrating this fact into its design. > > One approach could be a relatively simple document change, to > distinguish between specifying the information to be reported, as > distinct from the means of reporting it -- think of it as payload vs. > mechanism... Specify them separately. Then define both how to > incorporate the information directly and the form of an external > citation to it; this would eliminate the document's section on > 'alternatives' and treat the original and alternative methods as equal. > > d/ > > > > > > Detailed Comments: > >> 1. Introduction >> >> Most IETF participants are familiar with the saying, "rough >> consensus and running code" [Tao], and can identify with its >> pragmatic approach. However, there are many examples of >> Internet-Drafts containing protocol specification that have gone >> through to publication as Proposed Standard RFCs without >> implementation. Some of them may never get implemented. > > The "however" implies that it is wrong or problematic for Proposed to be > assigned to unimplemented protocols. It isn't. I suggest a softer > tone, while still noting the relevantfact. Something like: > > It is not a requirement of Proposed Standard status to have any > implementations; by the time of reaching that status, some > specifications have been implemented and some have not. Indeed, some > never get implemented. > > >> Over time, a variety of policies have been implemented within the > > implemented -> applied > > >> IETF to consider running code. In the Routing Area it used to be a >> requirement that one or more implementations must exist before an >> Internet-Draft could be published as a Proposed Standard RFC >> [RFC1264]. That RFC was later obsoleted and the requirement for >> implementation was lifted, but each working group was given the >> authority to impose its own implementation requirements [RFC4794] >> and at least one working group (IDR) continues to require two >> independent implementations. >> >> The hypothesis behind this document is that there are benefits to >> the > > this -> the current > > >> IETF standardization process of producing implementations of >> protocol specifications before publication as RFCs. These benefits, >> which > > I suspect that that isn't its "hypothesis" at all, since the document > does nothing to specify or directly affect policies for requiring or > encouraging implementation. Perhaps there is a hope that the proposed > notation about implementations will serve as some sort of encouragement, > but that's pretty indirect; success or failure of the proposed > experiment won't validate or invalidate whether there are benefits to > early implementation. And providing for a notation convention hardly > constitutes an 'incentive'. > > Rather, I believe the premise of the document is that the community is > aided by /more widely knowing about/ early implementations. This is splitting hairs: there would be no benefit in informing the community if there wasn't any benefit in the actual early implementations. But fine. > > >> include determining that the specification is comprehensible and >> that there is sufficient interest to implement, are further discussed >> in Section 4. >> >> This document describes a simple process that allows authors of > > process -> mechanism > > >> Internet-Drafts to record the status of known implementations, by >> including an Implementation Status section. The document defines >> (quite informally) the contents of this section, to ensure that the >> relevant information is included. This will allow reviewers and >> working groups to assign due consideration to documents that have >> the benefit of running code, by considering the running code as >> evidence of valuable experimentation and feedback that has made the >> implemented protocols more mature. > > The above last sentence seems to be the actual claimed value proposition > for the experiment. > I agree. > >> This document provides a mechanism to record and publicize the > > This sentence seems entirely redundant. > > >> existence of running code. It is up to the individual working >> groups to use this information as they see fit, but one result might >> be the preferential treatment of documents resulting in them being >> processed more rapidly. > > I think it won't be the working group that 'uses' the information, but > rather IETF management and the broader community? > For most documents, AFAIK, most work is done by the WG, and a lot less by the rest of the community. Hence the above. > >> The process in this document is offered as an experiment. Authors >> of Internet-Drafts are encouraged to consider using the process for >> their documents, and working groups are invited to think about >> applying the process to all of their protocol specifications. >> >> The scope of the intended experiment is all Internet-Drafts whether > > Probably not all I-Ds, since they do not all contain implementable > specifications. > > >> >> >> Sheffer & Farrel Expires October 14, 2013 [Page >> 3] Internet-Draft Running Code >> April 2013 >> >> >> produced within IETF working groups, outside working groups but > > What I-Ds are produced by "outside working groups"? I can't tell who > this refers to.It's probably just as well to remove the attempted case > analysis for groups and just say that the scope is all specifications > issued as I-Ds. In fact others have commented that we should exclude individual submissions for process reasons. > > >> intended for IETF consensus, or for publication on the Independent >> Stream. However, it is expected that most benefit from the > > that most benefit from the experiment will > -> > the greatest benefit in the experiment will > > >> experiment will be seen with Standards Track documents developed >> within working groups. > > Here's my guess: > > 1. Those offering comments or making decisions about the status of > document will be aided by this added information. > > 2. Those deciding about whether to write code or deploy it will be aided. > > I think the latter is likely to be the greater benefit. > > >> The authors of this document intend to collate experiences with this >> experiment and to report them to the community. >> >> >> 2. The "Implementation Status" Section >> >> Each Internet-Draft may contain a section entitled "Implementation >> Status". This section, if it appears, should be located just before >> the "Security Considerations" section and contain, for each existing >> implementation: >> >> o The implementation's name and/or a link to a web page describing >> the implementation. o A brief general description. o The >> implementation's level of maturity: research, prototype, alpha, beta, >> production, widely used etc. o Coverage: which parts of the protocol >> specification are implemented and which versions of the >> Internet-Draft were implemented. o Licensing: the terms under which >> the implementation can be used. For example: proprietary, royalty >> licensing, freely distributable with acknowledgement (BSD style), >> freely distributable with requirement to redistribute source (GPL >> style), other (specify). o Contact information: ideally a person's >> name and email address, but possibly just a URL or mailing list. > > List the organization that did the implementation and contact > information for the proper place in the organization. > > >> In addition, this section can contain information about the >> interoperability of any or all of the implementations. >> >> Since this information is necessarily time-dependent, it is >> inappropriate for inclusion in a published RFC. The authors should > > Way to bury the lead. This stuff won't be in the published document? > It's only for pre-publication? Very clearly YES. > > >> include a note to the RFC Editor requesting that the section be >> removed before publication. >> >> 2.1. Introductory Text >> >> The following boilerplate text is proposed to head the >> Implementation Status section: >> >> >> >> >> >> >> >> Sheffer & Farrel Expires October 14, 2013 [Page >> 4] Internet-Draft Running Code >> April 2013 >> >> >> This section records the status of known implementations of the >> protocol defined by this specification at the time of posting of this >> Internet-Draft, and is based on a proposal described in [RFC Editor: >> replace by a reference to this document]. According to [RFC Editor: >> replace by a reference to this document], "this will allow reviewers >> and working groups to assign due consideration to documents that have >> the benefit of running code, by considering the running code as >> evidence of valuable experimentation and feedback that has made the >> implemented protocols more mature. It is up to the individual >> working groups to use this information as they see fit". >> >> Authors are requested to add a note to the RFC Editor at the top of >> this section, advising the Editor to remove the entire section >> before publication, as well as the reference to [RFC Editor: replace >> by a reference to this document]. >> >> >> 3. Alternative Formats > > Yes! > > >> Sometimes it can be advantageous to publish the implementation >> status separately from the base Internet-Draft, e.g. on the IETF >> wiki: >> >> o When the Implementation Status section becomes too large to be >> conveniently managed within the document. o When a working group >> decides to have implementors, rather than authors, keep the status of >> their implementations current. o When a working group already >> maintains an active wiki and prefers to use it for this purpose. >> >> It is highly desirable for all readers of the Internet-Draft to be >> made aware of this information. Initially this can be done by >> replacing the Implementation Status section's contents with a URL >> pointing to the wiki. Later, the IETF Tools may support this >> functionality, e.g. by including such a link from the HTMLized draft >> version, similar to the IPR link. >> >> If the implementation status is published separately from the I-D, >> then this information needs to be openly available without requiring >> authentication, registration or access controls if it is to have any >> useful effects. >> >> >> 4. Benefits >> >> Publishing the information about implementations provides the >> working group with several benefits: >> >> >> >> >> Sheffer & Farrel Expires October 14, 2013 [Page >> 5] Internet-Draft Running Code >> April 2013 >> >> >> o Participants are motivated to implement protocol proposals, which >> helps in discovering protocol flaws at an early stage. > > The psychological premise seems to be that getting cited in this list > will somehow serve as an incentive to implementers. I can imagine that > they'll like being listed, but find it extremely difficult to believe > that it will affect whether they do the work; not that I think it's a > deciding factor, but note that the ego value is further reduced by the > information's being ephemeral, since it it removed prior to RFC > publication! Actually not (subtly so). The premise is making this information public and an explicit part of WG deliberations will incentivize implementations (i.e. not the ego factor at all). > > >> o Other participants can use the software, to evaluate the >> usefulness of protocol features, its correctness (to some degree) and >> other properties, such as resilience and scalability. > > Efficacy of the spec. > > >> o WG members may choose to perform interoperability testing with >> known implementations, especially when they are publicly available. > > Interoperability of the spec. > > >> o In the case of open source, people may want to study the code to >> better understand the protocol and its limitations, determine if the >> implementation matches the protocol specification, and whether the >> protocol specification has omissions or ambiguities. > > Reference implementation as exemplar. > > >> o Working group chairs and ADs may use the information provided to >> help prioritize the progress of I-Ds in some way. > > What does "prioritize the progress" mean? When there are multiple competing proposals to solve some problem. > > >> o Similarly, the information is useful when deciding whether the >> document should be progressed on a different track (individual >> submission, Experimental etc.). > Assess spec maturity. (This seems redundant with the combination of > Efficacy and Interoperability?) > > >> o And lastly, some protocol features may be hard to understand, and >> for such features, the mere assurance that they can be implemented is >> beneficial. > > mumble. Might highlight problems with the spec language. Might > undermine the spec text by causing code to be used in place of it? I'm with you on both mumbles. > > >> We do not specify here whether and to what degree working groups are >> expected to prefer proposals that have "running code" associated >> with them, over others that do not. >> >> >> 5. Process Experiment >> >> The current proposal is proposed as an experiment. The inclusion of >> "Implementation Status" sections in Internet-Drafts is not >> mandatory, but the authors of this document wish to encourage authors >> of other Internet-Drafts to try out this simple process to discover >> whether it is useful. Working group chairs are invited to suggest >> this process to document editors in their working groups, and to draw >> the attention of their working group participants to "Implementation >> Status" sections where they exist. >> >> Following a community discussion, it was concluded that [RFC3933] is >> not an appropriate framework for this experiment, primarily because >> no change is required to any existing process. > > It defines a document meta-data encoding mechanism. That's not really a > "process". > > >> 7. Security Considerations >> >> This is a process document and therefore, it does not have a direct >> effect on the security of any particular IETF protocol. Better > > Better -> However, better > > > d/ > From dhc@dcrocker.net Sun Apr 28 15:06:19 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EAD21F984E; Sun, 28 Apr 2013 15:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbkP8V4qFq6t; Sun, 28 Apr 2013 15:06:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4621F9832; Sun, 28 Apr 2013 15:06:18 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3SM69Zt004595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Apr 2013 15:06:15 -0700 Message-ID: <517D9D50.9010408@dcrocker.net> Date: Sun, 28 Apr 2013 15:06:08 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yaron Sheffer References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517AA859.9060804@dcrocker.net> <517D3A5C.4070009@gmail.com> In-Reply-To: <517D3A5C.4070009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 28 Apr 2013 15:06:17 -0700 (PDT) Cc: IESG , draft-sheffer-running-code@tools.ietf.org, Tools Team Discussion , "ietf@ietf.org" Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 22:06:19 -0000 On 4/28/2013 8:03 AM, Yaron Sheffer wrote: > Hi Dave, > > Thank you for your thorough review. While I accept many of your > comments, I must say I disagree with you on a few points, which together > go to the core of our motivation in writing this document. Thank you for > helping me clarify these points to myself :-) > > - Our goal is much *less* ambitious than defining a framework for > documenting implementations for long-term protocol projects. Our primary > goal is to aid working group members in making informed decisions about > the quality of specifications. Forgive me, but working group members seem like the /least/ interesting target audience, since it is already the most-informed group, by virtue of its direct activity over the course of developing the specification. The people who are most likely to benefit from pointers to implementation details are: 1. Reviewers, who want a sense of implementation history to 'season' their analysis; 2. IESG members, who are deciding whether to vote approval for the specification; and 3. Those considering adoption of the technology for use, such as other implementers and service operators. That said, what you propose certainly accommodates #1 and #2, without needing to agree on their being a target audience... [However the small discussion, farther down, about being better able to evaluate competing proposals, does provide an example of benefit /within/ the working group...] > - As a result of the above: 1. We define the information as pre-RFC > only; 2. The main medium is the I-D, as opposed to Web pages/wikis/CMS > (although we see them as valid alternatives); 3. We focus on WG > documents, as opposed to "all" IETF documents. Right. And here my suggestions were merely to clarify this earlier in the proposal document. > - Despite the glowing counterexample of DKIM, it is rarely practical to > maintain implementation status information, keeping it current for years > (put bluntly, you need to pay someone to do that). Would that I'd been getting paid... But yeah,it takes continuing effort. (On the other hand, there isn't much on-going work, after initial bursts of development activity.) At any rate, rather than insisting that the list be external and on-going, my intention was to suggest designing it to comfortably /allow/ the wg to make the choice of either, gracefully, including an easy transition from one to the other. - - - - - >>> existence of running code. It is up to the individual working >>> groups to use this information as they see fit, but one result might >>> be the preferential treatment of documents resulting in them being >>> processed more rapidly. >> >> I think it won't be the working group that 'uses' the information, but >> rather IETF management and the broader community? >> > > For most documents, AFAIK, most work is done by the WG, and a lot less > by the rest of the community. Hence the above. IETF Working groups do not create market demand and do not do develop or deployment. All of that is quite explicitly outside the scope of the IETF, and at industry-scale, they represent more aggregate effort than is put in by the IETF working group... >>> The scope of the intended experiment is all Internet-Drafts whether >> >> Probably not all I-Ds, since they do not all contain implementable >> specifications. >> >> >>> >>> >>> Sheffer & Farrel Expires October 14, 2013 [Page >>> 3] Internet-Draft Running Code >>> April 2013 >>> >>> >>> produced within IETF working groups, outside working groups but >> >> What I-Ds are produced by "outside working groups"? I can't tell who >> this refers to.It's probably just as well to remove the attempted case >> analysis for groups and just say that the scope is all specifications >> issued as I-Ds. > > In fact others have commented that we should exclude individual > submissions for process reasons. Right. That suggests writing the scoping text a bit more tightly. >>> o Participants are motivated to implement protocol proposals, which >>> helps in discovering protocol flaws at an early stage. >> >> The psychological premise seems to be that getting cited in this list >> will somehow serve as an incentive to implementers. I can imagine that >> they'll like being listed, but find it extremely difficult to believe >> that it will affect whether they do the work; not that I think it's a >> deciding factor, but note that the ego value is further reduced by the >> information's being ephemeral, since it it removed prior to RFC >> publication! > > Actually not (subtly so). The premise is making this information public > and an explicit part of WG deliberations will incentivize > implementations (i.e. not the ego factor at all). The statements you are making about "incentives" to implementers really are in terms of their ego, since you have not stated any other benefit that will accrue to /them/. There will be benefits to the community at large, but the question in this section of text is what the motivation of the implementer will be. >>> o Working group chairs and ADs may use the information provided to >>> help prioritize the progress of I-Ds in some way. >> >> What does "prioritize the progress" mean? > > When there are multiple competing proposals to solve some problem. I think you are trying to say something like: By having early implementation examples for competing proposals, the working group can better evaluate choices among them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alleyez0nm3x@live.com Sat Apr 20 18:59:47 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416E21F8709 for ; Sat, 20 Apr 2013 18:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[AWL=1.849, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtFVRhq2g-KU for ; Sat, 20 Apr 2013 18:59:47 -0700 (PDT) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id D60BA21F86BA for ; Sat, 20 Apr 2013 18:59:46 -0700 (PDT) Received: from BLU404-EAS208 ([65.55.111.73]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Apr 2013 18:59:46 -0700 X-EIP: [kW9acuxll9q7dOwyEkxcvbwiBckGNtQ3] X-Originating-Email: [alleyez0nm3x@live.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Anthony Marel Date: Sat, 20 Apr 2013 21:59:43 -0400 To: "tools-discuss@ietf.org" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 21 Apr 2013 01:59:46.0880 (UTC) FILETIME=[E6535C00:01CE3E33] X-Mailman-Approved-At: Mon, 29 Apr 2013 03:12:19 -0700 Subject: [Tools-discuss] Idnits-2.12.16 feedback X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 01:59:47 -0000 From john-ietf@jck.com Fri Apr 26 09:50:53 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0414421F9A24; Fri, 26 Apr 2013 09:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnDx-MeNR3Em; Fri, 26 Apr 2013 09:50:52 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 078BA21F9A23; Fri, 26 Apr 2013 09:50:52 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UVlrF-000HvP-NF; Fri, 26 Apr 2013 12:50:49 -0400 Date: Fri, 26 Apr 2013 12:50:44 -0400 From: John C Klensin To: "Fred Baker (fred)" , Yaron Sheffer Message-ID: <0E1D18E70456E3EEE8A2BEC0@JcK-HP8200.jck.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517A44F2.9050009@gmail.com> <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 29 Apr 2013 03:12:19 -0700 Cc: "" , "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:50:53 -0000 --On Friday, April 26, 2013 16:07 +0000 "Fred Baker (fred)" wrote: > > On Apr 26, 2013, at 2:12 AM, Yaron Sheffer > wrote: > >> - There should be long-term commitment to maintain the data. >> I think we simply don't have such processes in place, and >> personally I don't want to even try to deal with this >> problem. I suspect that we'd have to eventually use paid help >> if we are serious about keeping the information current, and >> I don't even think it would be worth the cost. > > Understood. That said, we already have working group wikis and > errata. I don't want to trivialize the investment, but it > seems like we have at least part of the infrastructure > already. I'm asking what will be the best for IETF discussion > and for maintenance of the information. I suspect it's > something we can do if we choose to. Fred, First, I agree with both the above and with your prior note agreeing with the general idea and suggesting something more "live" than a section of an I-D. Second, while I certainly see the value, I would get nervous if we were to move significantly toward a long-term, IETF-supported, official statement or compendium of implementation status. At least unless pursued with great caution [1], such a thing would raise some of the same issues that going into the conformance testing business does in terms of the perception of guarantees that a given implementation is somehow "IETF approved". Perhaps the right model would be to keep this material in I-Ds (as the proposal suggests) to support the evolution and review of specification documents, then to move it to a wiki or equivalent that was clearly identified as unofficial and for the convenience of the community and that was "maintained by the IETF" only to the extent needed to minimize spam, libel, and other nonsense. It also occurs to me that an alternative to part of the experiment (still consistent with it, IMO) would be to start the wiki process earlier and use the I-Ds merely to snapshot the wiki at various points to help in the review process. That would give both the advantages of a continually-evolving list and those of periodic stable snapshots. Just a thought or two. john [1] Images of dragging along as small pack of lawyers, albatross-like, are probably in order. From john-ietf@jck.com Sun Apr 28 07:35:56 2013 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9865E21F99BB; Sun, 28 Apr 2013 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMeVmnaWdrHS; Sun, 28 Apr 2013 07:35:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA7921F99B3; Sun, 28 Apr 2013 07:35:55 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UWShk-000Ofn-RF; Sun, 28 Apr 2013 10:35:52 -0400 Date: Sun, 28 Apr 2013 10:35:47 -0400 From: John C Klensin To: adrian@olddog.co.uk, "'Fred Baker (fred)'" , 'Yaron Sheffer' Message-ID: <08093B669F43658F8972DD91@JcK-HP8200.jck.com> In-Reply-To: <013f01ce4402$9f5a9460$de0fbd20$@olddog.co.uk> References: <20130412215712.8482.32099.idtracker@ietfa.amsl.com> <517A44F2.9050009@gmail.com> <8C48B86A895913448548E6D15DA7553B8242FA@xmb-rcd-x09.cisco.com> <0E1D18E70456E3EEE8A2BEC0@JcK-HP8200.jck.com> <013f01ce4402$9f5a9460$de0fbd20$@olddog.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 29 Apr 2013 03:12:19 -0700 Cc: ietf@ietf.org, tools-discuss@ietf.org Subject: Re: [Tools-discuss] Last Call: (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 14:35:56 -0000 --On Sunday, April 28, 2013 12:22 +0100 Adrian Farrel wrote: > Hi John, > > Seems consistent with what is in the I-D at the moment. See > section 3. > > Thus, those who want to record the info in the I-D can do > that, while those who want to go straight to a wiki can do > that (although we ask that the I-D has a pointer to the wiki). Indeed. I was trying to make that point in a different way. To be more explicit, I think the I-D is fine, precisely because it allows some reasonable flexibility about that sort of option. I'd encourage the experimental evaluation process to compare those two options in practice (e.g., by including statistics about which method is used in the Summary Report (Section 5.2) and commenting on relative utility if there is anything to say). But there is nothing in the I-D that would prevent that and I'm not convinced that more specifics in this I-D would be worth the trouble. john