From grjaques@cyberhighway.net Thu Feb 02 19:30:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oqN-0007B9-PL for newtrk-archive@megatron.ietf.org; Thu, 02 Feb 2006 19:30:32 -0500 Received: from hzyfwlifl.com ([218.73.218.254]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03098 for ; Thu, 2 Feb 2006 19:28:33 -0500 (EST) Received: (accent 16312 invoked from network); Thu, 02 Feb 2006 14:36:43 -0500 Date: Thu, 02 Feb 2006 18:15:14 -0500 From: Aisha Terrell X-Mailer: amply 28.843.32513 Reply-To: Myles Stanton X-Priority: 3 (Normal) Message-ID: <48367384753514956395778@cyberhighway.net> To: newtrk-archive@ietf.org Subject: Amazing, Rich In-Reply-To: <682310286343380507765370@cyberhighway.net> References: <22013710526005885651081@cyberhighway.net> MIME-Version: 1.0 X-MSMail-Priority: Normal X-MimeOLE: crusoe 98.394.8707 Content-Type: multipart/mixed; boundary="------=8211488209" Content-Transfer-Encoding: 7bit --------=8211488209 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Those men are most apt to be obsequious and conciliating abroad, who are under the discipline of shrews at home.Freedom begins as we become conscious of it.
Sometimes something worth doing is worth overdoing. --------=8211488209 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Raquel-> http://tqkcet.allworlda.info/?23595030 --------=8211488209-- From owner-newtrk@lists.uoregon.edu Tue Feb 07 08:20:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6SlI-0007IE-Vy for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 08:20:05 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24541 for ; Tue, 7 Feb 2006 08:18:20 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/Ix9Xveulf9orm3H+t7tfDXu0ZqzLxnvg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17D9rkv015539; Tue, 7 Feb 2006 05:09:53 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17D9rIr015538; Tue, 7 Feb 2006 05:09:53 -0800 Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17D9rQT015531 for ; Tue, 7 Feb 2006 05:09:53 -0800 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc12) with SMTP id <20060207130947012007v9rse>; Tue, 7 Feb 2006 13:09:47 +0000 Message-ID: <095701c62be7$93d8da60$3703a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20060207010451.512573C022E@berkshire.machshav.com> Subject: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC) Date: Tue, 7 Feb 2006 07:08:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Not sure what Newtrk will be up to after Dallas, but the following exhange appeared on the IETF Discussion list: >>> This document has been reviewed in the IETF but is not the product of an >>> IETF Working Group. >> >>Was there a last call for this document? I do not recall seeing it. >> > Informational RFCs do not require Last Calls. Maybe I should go get a(nother) Diet Pepsi, but this just strikes me wrong I'm not questioning that it's allowed by our current process - please don't think that. I'm just a lot more comfortable with the idea that anything that gets "reviewed in the IETF" gets "last-called in the IETF", and that anything that doesn't get "last-called in the IETF" would list specific reviewers, rather than spreading the credit/blame in all directions. Thoughts from others? Spencer . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 08:22:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Snm-00080l-Pr for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 08:22:40 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24653 for ; Tue, 7 Feb 2006 08:20:49 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+FhPhrtNN9bJTEUw7SZgDqqpiFvQ/PNYw@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DGZ8w015764; Tue, 7 Feb 2006 05:16:35 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17DGZqb015763; Tue, 7 Feb 2006 05:16:35 -0800 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DGYR0015758 for ; Tue, 7 Feb 2006 05:16:34 -0800 Received: by newdev.harvard.edu (Postfix, from userid 501) id EDEDE64DEC8; Tue, 7 Feb 2006 08:16:28 -0500 (EST) To: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure ... Message-Id: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> Date: Tue, 7 Feb 2006 08:16:28 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Spencer opines > I'm just a lot more comfortable with the idea that anything that gets > "reviewed in the IETF" gets "last-called in the IETF", and that anything > that doesn't get "last-called in the IETF" would list specific reviewers, > rather than spreading the credit/blame in all directions. I, for 1, fully agree Scott . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 08:58:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TMD-00035D-Dw for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 08:58:13 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27291 for ; Tue, 7 Feb 2006 08:56:23 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+9T213QteO5TfMxbnJVvaw9lRzyOZ9n2s@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DtUpL016072; Tue, 7 Feb 2006 05:55:30 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17DtUq6016071; Tue, 7 Feb 2006 05:55:30 -0800 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DtT6r016066 for ; Tue, 7 Feb 2006 05:55:29 -0800 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2006 05:55:25 -0800 X-IronPort-AV: i="4.02,94,1139212800"; d="scan'208"; a="1774139882:sNHT30550928" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k17DtOQJ018312; Tue, 7 Feb 2006 05:55:24 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4412.cisco.com [10.61.81.59]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k17Dx0YN001308; Tue, 7 Feb 2006 05:59:01 -0800 Message-ID: <43E8A6CB.5060303@cisco.com> Date: Tue, 07 Feb 2006 14:55:23 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Spencer Dawkins CC: newtrk@lists.uoregon.edu Subject: [newtrk] Next steps References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> In-Reply-To: <095701c62be7$93d8da60$3703a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1228; t=1139320741; x=1139752941; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Next=20steps |To:Spencer=20Dawkins=20; X=v=3Dmtcc.com=3B=20h=3Dn/Azf828ihhhZNB61xl5PGgLUqE=3D; b=DdHnajc9/kRT7mCgFAJauEujZZHavIFGNkrI4xdDW1+OhJdWZIN9iK6QXWxf2M/X8NccYGkz fK6tBpFfuYiqXABw04Ys+emO4ijMO1Dqg77oLNUw7V0doeQYwmcG4hLdkDska5QJsNWhlsJ1eTU Z386mG+bO6sB/TJrwRKyi1Sw=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > Not sure what Newtrk will be up to after Dallas, but the following > exhange appeared on the IETF Discussion list: > This raises the question of where NEWTRK should go from here. There are a few possibilities: 1. Further formalize the cruft process. As it stands now we did a one-off involving only proposed standards prior to 2000. We could give some thought to whether and when other documents should be reviewed. For instance, What about draft and full? Are they sacrosanct? What about RFCs 2000-3000. If we look at RFC 3000, that document is now five years old. And then when if ever do we return to the PSes that are still live? 2. Of the PSes that are still around, they should be advanced somehow. I think if they've withstood the test of time and the decruft process, perhaps we should consider having them advanced at this point without an implementation report. Certainly nobody is going to tinker with, for example, most telnet options. 3. Should we combine draft/full standard status? Hasn't time shown that doing the work for draft should be enough? Just some thoughts. Eliot . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 09:05:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TSu-0005nw-47 for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 09:05:08 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27854 for ; Tue, 7 Feb 2006 09:03:18 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX195w3NgiXjTNmJpaEkk5RVnTRWKklfn2Ao@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DwsiG016117; Tue, 7 Feb 2006 05:58:54 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17DwsMv016116; Tue, 7 Feb 2006 05:58:54 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17DwrFU016111 for ; Tue, 7 Feb 2006 05:58:53 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F6TMq-0008f2-Ju; Tue, 07 Feb 2006 08:58:52 -0500 Date: Tue, 07 Feb 2006 08:58:51 -0500 From: John C Klensin To: Spencer Dawkins , newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC) Message-ID: <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> In-Reply-To: <095701c62be7$93d8da60$3703a8c0@china.huawei.com> References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 07 February, 2006 07:08 -0600 Spencer Dawkins wrote: > I'm just a lot more comfortable with the idea that anything > that gets "reviewed in the IETF" gets "last-called in the > IETF", and that anything that doesn't get "last-called in the > IETF" would list specific reviewers, rather than spreading the > credit/blame in all directions. In principle, I agree. But we should not make this change without considering the system of which it is a part. Right now, "reviewed in the IETF" is a code for "the IESG looked at it and make a decision; it was not processed directly by the RFC Editor". The alternative today is a disclaimer about non-approval by the IETF that is so strong as to imply that the IETF (or at least the IESG) _has_ reviewed the document and concluded that it is trash. The RFC Editor does get independent submission documents which were quietly posted as I-Ds and to which the IETF community paid no attention. But the cases you are talking about, and for which you want to name reviewers, are in a gray area. In many cases, they have been posted as I-Ds, extensively discussed on IETF-related mailing lists, updated several times as the result of moderately broad IETF community feedback, etc. In a few cases, they have gotten more practical consideration, by more members of the IETF community, than some documents that are approved for standards-track designations. To the extent to which one insists that those go through the IESG to avoid the disclaimer and to which you insist that the IESG issue a Last Call in order to say "discussed in the IETF", you are increasing the workload on the IESG (workload that RFC 3932 was, in part, intended to reduce) and adding to the number of "noise" Last Calls circulated in the community. I don't think either outcome is desirable. Moreover, there is a case to be made that, if I document is widely-circulated and discussed in the IETF Community, but the IESG does not decide it important enough to issue a Last Call, it should not be distinguished from a similar document that goes through the independent submission path. Remember that we try to avoid trying to get into the "seal of approval" model and that we want to treat both IESG and IETF community time as valuable. To that end, I'd prefer to see the IESG issue Last Calls only on issues for which the IESG believes that community feedback is important and valuable ... not because they want to attach some particular level of implied endorsement or avoid a different one. That might mean we need to rethink our definitions, especially of "Informational". But simply tuning the Last Call rules and their relationship to specific language seems to me to be the sort of point-tuning of procedures that keeps getting us into trouble. john p.s. Some of the above comments would overlap significantly with the TechSpec discussions, if the TechSpec discussions were part of a WG effort. But they aren't -- they are technically a design team effort that uses an IETF mailing list -- so there can't be any fatal overlap with them. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 09:06:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TUE-0006iT-4C for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 09:06:32 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27986 for ; Tue, 7 Feb 2006 09:04:41 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/o3xfrH8iKpFxCgTIWf+cmkpld7+gRI50@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17E45V1016182; Tue, 7 Feb 2006 06:04:05 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17E45mr016181; Tue, 7 Feb 2006 06:04:05 -0800 Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17E44j6016176 for ; Tue, 7 Feb 2006 06:04:05 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k17E424f023397; Tue, 7 Feb 2006 08:04:03 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Feb 2006 15:04:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155094336DA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Spencer Dawkins , newtrk@lists.uoregon.edu Subject: RE: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'U S Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC) Date: Tue, 7 Feb 2006 15:03:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk If it is an Informational doc from a WG, then at least that WG should have reviewed it (i.e. via a WGLC). Further, the IESG does review it, and so possibly various directorates and review-teams get to review it (if they pick up on it). And in some cases when the AD feels it deserves wider review, he/she will issue an IETF Last Call (IETF LC is not required, but is allowed if AD or IESG feels it desereves it). Or so is my understanding. Bert > -----Original Message----- > From: owner-newtrk@lists.uoregon.edu > [mailto:owner-newtrk@lists.uoregon.edu]On Behalf Of Spencer Dawkins > Sent: Tuesday, February 07, 2006 14:08 > To: newtrk@lists.uoregon.edu > Subject: [newtrk] "Reviewed in the IETF" (was: Re: Document > Action: 'US > Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC) > > > Not sure what Newtrk will be up to after Dallas, but the > following exhange > appeared on the IETF Discussion list: > > >>> This document has been reviewed in the IETF but is not > the product of an > >>> IETF Working Group. > >> > >>Was there a last call for this document? I do not recall seeing it. > >> > > Informational RFCs do not require Last Calls. > > Maybe I should go get a(nother) Diet Pepsi, but this just > strikes me wrong > > I'm not questioning that it's allowed by our current process > - please don't > think that. > > I'm just a lot more comfortable with the idea that anything that gets > "reviewed in the IETF" gets "last-called in the IETF", and > that anything > that doesn't get "last-called in the IETF" would list > specific reviewers, > rather than spreading the credit/blame in all directions. > > Thoughts from others? > > Spencer > > > . > newtrk resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 10:31:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6UoJ-0001bj-A2 for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 10:31:20 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03876 for ; Tue, 7 Feb 2006 10:29:26 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+8P+lpqhSzamCN1MYzj5mEjAftjtkVLb4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17FPi1G017524; Tue, 7 Feb 2006 07:25:44 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17FPioN017523; Tue, 7 Feb 2006 07:25:44 -0800 Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.29.150]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17FPhng017512 for ; Tue, 7 Feb 2006 07:25:44 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k17FPa7i045684 for ; Tue, 7 Feb 2006 15:25:37 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k17FPajc240558 for ; Tue, 7 Feb 2006 16:25:36 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k17FPaLX015654 for ; Tue, 7 Feb 2006 16:25:36 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k17FPZ53015645 for ; Tue, 7 Feb 2006 16:25:35 +0100 Received: from zurich.ibm.com (sig-9-145-129-147.de.ibm.com [9.145.129.147]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA39960 for ; Tue, 7 Feb 2006 16:25:34 +0100 Message-ID: <43E8BBED.7040909@zurich.ibm.com> Date: Tue, 07 Feb 2006 16:25:33 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure ... References: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> In-Reply-To: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Scott Bradner wrote: > Spencer opines > >>I'm just a lot more comfortable with the idea that anything that gets >>"reviewed in the IETF" gets "last-called in the IETF", and that anything >>that doesn't get "last-called in the IETF" would list specific reviewers, >>rather than spreading the credit/blame in all directions. > > > I, for 1, fully agree > Hopefully, the comments in the tracker will indicate who has reviewed the document. As in: Working Group Summary This is an Individual submission. No IETF Working Group was involved. Protocol Quality This document was reviewed by Russ Housley for the IESG. In this particular case, since Most of the text in the document was adapted by the authors from FIPS 180-2. last-calling would have been a bit over the top IMHO. Brian . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 11:20:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VaH-0006eS-NJ for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 11:20:54 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07772 for ; Tue, 7 Feb 2006 11:19:11 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/9eDRpdIkzgnrOT/1xZWoMYoCMb8Pb3Xo@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17GF4sZ018398; Tue, 7 Feb 2006 08:15:04 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17GF4DE018397; Tue, 7 Feb 2006 08:15:04 -0800 Received: from mtagate4.uk.ibm.com (mtagate4.uk.ibm.com [195.212.29.137]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17GEwaR018272 for ; Tue, 7 Feb 2006 08:15:04 -0800 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k17GEql6059788 for ; Tue, 7 Feb 2006 16:14:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k17GEqNT211046 for ; Tue, 7 Feb 2006 16:14:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k17GEpYw023185 for ; Tue, 7 Feb 2006 16:14:51 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k17GEptH023178; Tue, 7 Feb 2006 16:14:51 GMT Received: from zurich.ibm.com (sig-9-145-129-147.de.ibm.com [9.145.129.147]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA53358; Tue, 7 Feb 2006 17:14:50 +0100 Message-ID: <43E8C779.7010409@zurich.ibm.com> Date: Tue, 07 Feb 2006 17:14:49 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Eliot Lear CC: Spencer Dawkins , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Next steps References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <43E8A6CB.5060303@cisco.com> In-Reply-To: <43E8A6CB.5060303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit There will be a General Area open meeting in Dallas, where both newtk and pesci next steps will be on the agenda. Brian Eliot Lear wrote: > Spencer Dawkins wrote: > >>Not sure what Newtrk will be up to after Dallas, but the following >>exhange appeared on the IETF Discussion list: >> > > This raises the question of where NEWTRK should go from here. There are > a few possibilities: > > 1. Further formalize the cruft process. As it stands now we did a > one-off involving only proposed standards prior to 2000. We could > give some thought to whether and when other documents should be > reviewed. For instance, What about draft and full? Are they > sacrosanct? What about RFCs 2000-3000. If we look at RFC 3000, > that document is now five years old. And then when if ever do we > return to the PSes that are still live? > 2. Of the PSes that are still around, they should be advanced > somehow. I think if they've withstood the test of time and the > decruft process, perhaps we should consider having them advanced > at this point without an implementation report. Certainly nobody > is going to tinker with, for example, most telnet options. > 3. Should we combine draft/full standard status? Hasn't time shown > that doing the work for draft should be enough? > > Just some thoughts. > > Eliot > . > newtrk resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 11:45:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Vxj-0007QD-HA for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 11:45:09 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09492 for ; Tue, 7 Feb 2006 11:43:24 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/CTxFUTudHmsr7vLJtWN7Y4bJ53xwLqCQ@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17GdAQm018979; Tue, 7 Feb 2006 08:39:10 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17Gd9U4018978; Tue, 7 Feb 2006 08:39:09 -0800 Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17Gd9XW018973 for ; Tue, 7 Feb 2006 08:39:09 -0800 Received: from [64.100.227.83] ([::ffff:64.100.227.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 07 Feb 2006 11:38:25 -0500 id 015880B5.43E8CD02.0000216A Message-ID: <43E8CD21.6090306@thinkingcat.com> Date: Tue, 07 Feb 2006 11:38:57 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: Spencer Dawkins , newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> In-Reply-To: <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Point of clarification: TechSpec is not a design team. TechSpec is in (pre)BoF state. There are 2 document editors, who are tracking what is going on the public mailing list and updating the document for discussion at our next (bof) meeting. Someone *is* being a bit draconian about keeping the discussion focused on the stated purpose, but she's still (afaik) being consistent with BoF practices. It could become a WG, if that's what's required. John C Klensin wrote: > p.s. Some of the above comments would overlap significantly > with the TechSpec discussions, if the TechSpec discussions were > part of a WG effort. But they aren't -- they are technically a > design team effort that uses an IETF mailing list -- so there > can't be any fatal overlap with them. > > . > newtrk resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 12:24:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6WZm-0006Ds-FT for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 12:24:26 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13968 for ; Tue, 7 Feb 2006 12:22:45 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX191R49ab4K5BPvIgNPSi/O5VuX1dQSHDvw@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17HLw5W020060; Tue, 7 Feb 2006 09:21:58 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17HLwV3020059; Tue, 7 Feb 2006 09:21:58 -0800 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17HLwPC020041 for ; Tue, 7 Feb 2006 09:21:58 -0800 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc12) with SMTP id <20060207172100012008519oe>; Tue, 7 Feb 2006 17:21:00 +0000 Message-ID: <0a0f01c62c0a$ab0c8f60$3703a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC) Date: Tue, 7 Feb 2006 11:19:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear John, I've now had my first Diet Pepsi of the morning - it might be a detectable improvement in IETF process discussions if Ray provided Diet Pepsi in a faucet at my house every day, but I digress. I'm still not entirely comfortable with our use of Informational to cover at least different types of documents ("Independent" and "Individual" submissions, plus working group Informationals), but it sounds like you have the same concerns (if I interpreted your note correctly). I'm also reacting to what seems like cases of the words we use not actually meaning what anyone outside the IETF would guess that they mean. Thanks for the reminder on the larger picture. Up-leveling is always appropriate. Spencer From: "John C Klensin" > --On Tuesday, 07 February, 2006 07:08 -0600 Spencer Dawkins > wrote: > >> I'm just a lot more comfortable with the idea that anything >> that gets "reviewed in the IETF" gets "last-called in the >> IETF", and that anything that doesn't get "last-called in the >> IETF" would list specific reviewers, rather than spreading the >> credit/blame in all directions. > > In principle, I agree. But we should not make this change > without considering the system of which it is a part. Right > now, "reviewed in the IETF" is a code for "the IESG looked at it > and make a decision; it was not processed directly by the RFC > Editor". The alternative today is a disclaimer about > non-approval by the IETF that is so strong as to imply that the > IETF (or at least the IESG) _has_ reviewed the document and > concluded that it is trash. > > The RFC Editor does get independent submission documents which > were quietly posted as I-Ds and to which the IETF community paid > no attention. But the cases you are talking about, and for > which you want to name reviewers, are in a gray area. In many > cases, they have been posted as I-Ds, extensively discussed on > IETF-related mailing lists, updated several times as the result > of moderately broad IETF community feedback, etc. In a few > cases, they have gotten more practical consideration, by more > members of the IETF community, than some documents that are > approved for standards-track designations. To the extent to > which one insists that those go through the IESG to avoid the > disclaimer and to which you insist that the IESG issue a Last > Call in order to say "discussed in the IETF", you are increasing > the workload on the IESG (workload that RFC 3932 was, in part, > intended to reduce) and adding to the number of "noise" Last > Calls circulated in the community. > > I don't think either outcome is desirable. Moreover, there is > a case to be made that, if I document is widely-circulated and > discussed in the IETF Community, but the IESG does not decide it > important enough to issue a Last Call, it should not be > distinguished from a similar document that goes through the > independent submission path. Remember that we try to avoid > trying to get into the "seal of approval" model and that we want > to treat both IESG and IETF community time as valuable. To that > end, I'd prefer to see the IESG issue Last Calls only on issues > for which the IESG believes that community feedback is important > and valuable ... not because they want to attach some particular > level of implied endorsement or avoid a different one. That > might mean we need to rethink our definitions, especially of > "Informational". But simply tuning the Last Call rules and > their relationship to specific language seems to me to be the > sort of point-tuning of procedures that keeps getting us into > trouble. > > john > > p.s. Some of the above comments would overlap significantly > with the TechSpec discussions, if the TechSpec discussions were > part of a WG effort. But they aren't -- they are technically a > design team effort that uses an IETF mailing list -- so there > can't be any fatal overlap with them. > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 15:58:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Zuf-0008V0-MQ for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 15:58:14 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00281 for ; Tue, 7 Feb 2006 15:56:29 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18BFareVpyHlL5N+0lVykwy7a9sxBgs85E@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17KpO5L025100; Tue, 7 Feb 2006 12:51:24 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17KpNfP025099; Tue, 7 Feb 2006 12:51:23 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17KpMU3025094 for ; Tue, 7 Feb 2006 12:51:23 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F6Zo1-0009fy-Gu; Tue, 07 Feb 2006 15:51:21 -0500 Date: Tue, 07 Feb 2006 15:51:20 -0500 From: John C Klensin To: Leslie Daigle cc: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" Message-ID: In-Reply-To: <43E8CD21.6090306@thinkingcat.com> References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> <43E8CD21.6090306@thinkingcat.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 07 February, 2006 11:38 -0500 Leslie Daigle wrote: > Point of clarification: TechSpec is not a design team. > TechSpec is in (pre)BoF state. There are 2 document editors, > who are tracking what is going on the public mailing list and > updating the document for discussion at our next (bof) > meeting. Someone *is* being a bit draconian about keeping the > discussion focused on the stated purpose, but she's still > (afaik) being consistent with BoF practices. > It could become a WG, if that's what's required. Leslie, I raised that point because, in the midst of the DKIM discussion on the IETF list, what I considered a very important point largely got lost in the broader discussion. In particular, the question of "what is the status of agreements reached in pre-WG discussions vis-a-vis constraining either the discussions of the WG or responses to a hypothetical Last Call. If one looks narrowly at a set of discussions whose purpose is to get a BOF together than might lead to either a WG or a non-WG but standards track submission, then the nominal focus of those discussions is to demonstrate community interest and ability to reach meaningful consensus about something. But, under any procedures we have, the specifics of a substantive proposal that comes out of the effort are proof of concept rather than in any way binding on a future WG or a basis on which a Last Call objection can be ignored because the issue has already been discussed and decided. We have language to describe the groups that produce such substantive, but non-binding, decisions. The term we use is "design team" and we have some rather specific language in our procedures about what design teams can and cannot do and, in particular, about the degree to which design teams can assume their outputs are binding on the community and that they have change control over them. It seems to me that the "design team" constraints apply whether one comes into existence wrt an existing WG or is pre-BOF, and regardless of what one calls the group. It also appears to me that we've only got three forms of document-creation efforts -- individuals, design teams, and WGs. If something is treated as a WG wrt the presumed authority of the decisions it is making, then either it is a WG with a charter on which there is community consensus or, intentionally or not, it is a subversion of the process. As I understood it, that was the difficulty with both DKIM and with Pesci. The major difference between the two was that DKIM really was treated the way we treat design teams: the group produced a document, the community was not satisfied with it, the group went back to the drawing board. With DKIM, the group produced a proposal but it was claimed that the proposal should have some special status in the WG because it had been developed by a group of people who were IETF-experienced, had put a lot of energy into it, and had followed open procedures. The other difference is that I believe we need to be far more careful about groups who are developing procedures than we do about technical/ engineering work. As another type of example that both of us have fought to keep in balance, if the IAB were to produce a proposal for standardization of some technology, the status of that proposal, once it got into IETF processing, would be precisely equivalent to the status accorded a design team proposal even though that particular design team might well be presumed to have above-average insights and mechanisms for determining community consensus. So, call it what you will, I believe that either (i) TechSpec is, to the degree to which it produces a specific proposal or set of proposal, constrained by the same constraints that apply to design teams or (ii) it is an unchartered WG (an entity we don't have) and will remain so until there is a community-consensus charter and statement of tasks. regards, john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 16:03:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ZzT-0002Ot-43 for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 16:03:11 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01137 for ; Tue, 7 Feb 2006 16:01:28 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18DL1XUe9anQ0LbSZdEmOjuZqUSgOnaFR8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17KvOs1025311; Tue, 7 Feb 2006 12:57:24 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17KvOrk025310; Tue, 7 Feb 2006 12:57:24 -0800 Received: from zeke.ecotroph.net (zeke.toscano.org [69.31.8.124]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17KvMPJ025305 for ; Tue, 7 Feb 2006 12:57:24 -0800 Received: from [64.100.227.83] ([::ffff:64.100.227.83]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 07 Feb 2006 15:56:38 -0500 id 015880BE.43E90986.000051BE Message-ID: <43E909A6.5090205@thinkingcat.com> Date: Tue, 07 Feb 2006 15:57:10 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> <43E8CD21.6090306@thinkingcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Then we're largely in agreement, as I was not being sensitive to your specific point about status of the actual document and eventual last call or other input. What I was specifically addressing wrt TechSpec is that there is no special status of the document because of its editorship or who is providing input. The design team is open. Which (to repeat myself) sounds like we're in agreement. Leslie. John C Klensin wrote: > > --On Tuesday, 07 February, 2006 11:38 -0500 Leslie Daigle > wrote: > > >>Point of clarification: TechSpec is not a design team. >>TechSpec is in (pre)BoF state. There are 2 document editors, >>who are tracking what is going on the public mailing list and >>updating the document for discussion at our next (bof) >>meeting. Someone *is* being a bit draconian about keeping the >>discussion focused on the stated purpose, but she's still >>(afaik) being consistent with BoF practices. > > >>It could become a WG, if that's what's required. > > > Leslie, > > I raised that point because, in the midst of the DKIM discussion > on the IETF list, what I considered a very important point > largely got lost in the broader discussion. In particular, the > question of "what is the status of agreements reached in pre-WG > discussions vis-a-vis constraining either the discussions of the > WG or responses to a hypothetical Last Call. > > If one looks narrowly at a set of discussions whose purpose is > to get a BOF together than might lead to either a WG or a non-WG > but standards track submission, then the nominal focus of those > discussions is to demonstrate community interest and ability to > reach meaningful consensus about something. But, under any > procedures we have, the specifics of a substantive proposal that > comes out of the effort are proof of concept rather than in any > way binding on a future WG or a basis on which a Last Call > objection can be ignored because the issue has already been > discussed and decided. > > We have language to describe the groups that produce such > substantive, but non-binding, decisions. The term we use is > "design team" and we have some rather specific language in our > procedures about what design teams can and cannot do and, in > particular, about the degree to which design teams can assume > their outputs are binding on the community and that they have > change control over them. It seems to me that the "design team" > constraints apply whether one comes into existence wrt an > existing WG or is pre-BOF, and regardless of what one calls the > group. It also appears to me that we've only got three forms of > document-creation efforts -- individuals, design teams, and WGs. > If something is treated as a WG wrt the presumed authority of > the decisions it is making, then either it is a WG with a > charter on which there is community consensus or, intentionally > or not, it is a subversion of the process. > > As I understood it, that was the difficulty with both DKIM and > with Pesci. The major difference between the two was that DKIM > really was treated the way we treat design teams: the group > produced a document, the community was not satisfied with it, > the group went back to the drawing board. With DKIM, the group > produced a proposal but it was claimed that the proposal should > have some special status in the WG because it had been developed > by a group of people who were IETF-experienced, had put a lot of > energy into it, and had followed open procedures. The other > difference is that I believe we need to be far more careful > about groups who are developing procedures than we do about > technical/ engineering work. > > As another type of example that both of us have fought to keep > in balance, if the IAB were to produce a proposal for > standardization of some technology, the status of that proposal, > once it got into IETF processing, would be precisely equivalent > to the status accorded a design team proposal even though that > particular design team might well be presumed to have > above-average insights and mechanisms for determining community > consensus. > > So, call it what you will, I believe that either (i) TechSpec > is, to the degree to which it produces a specific proposal or > set of proposal, constrained by the same constraints that apply > to design teams or (ii) it is an unchartered WG (an entity we > don't have) and will remain so until there is a > community-consensus charter and statement of tasks. > > regards, > john > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 16:09:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6a5T-0005de-2B for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 16:09:23 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01921 for ; Tue, 7 Feb 2006 16:07:40 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19NB3s4mbj0KvJbnkJa0YAYIa1hmSiG1+A@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17L5P84025465; Tue, 7 Feb 2006 13:05:25 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17L5PPN025464; Tue, 7 Feb 2006 13:05:25 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17L5O78025459 for ; Tue, 7 Feb 2006 13:05:24 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F6a1b-0009ho-MN; Tue, 07 Feb 2006 16:05:23 -0500 Date: Tue, 07 Feb 2006 16:05:21 -0500 From: John C Klensin To: Leslie Daigle cc: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" Message-ID: <112C9E7297583744ABFCD74B@p3.JCK.COM> In-Reply-To: <43E909A6.5090205@thinkingcat.com> References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> <43E8CD21.6090306@thinkingcat.com> <43E909A6.5090205@thinkingcat.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 07 February, 2006 15:57 -0500 Leslie Daigle wrote: > Then we're largely in agreement, as I was not being sensitive > to your specific point about status of the actual document > and eventual last call or other input. > > What I was specifically addressing wrt TechSpec is that > there is no special status of the document because of its > editorship or who is providing input. The design team > is open. > > Which (to repeat myself) sounds like we're in agreement. yes thanks, john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 18:43:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6cUW-0004jo-91 for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 18:43:27 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11865 for ; Tue, 7 Feb 2006 18:41:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18KPPlYH/NiHI5ZIws+d6Uv11IZR/stC4U@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17NefZ8029789; Tue, 7 Feb 2006 15:40:41 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k17Nef2L029788; Tue, 7 Feb 2006 15:40:41 -0800 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k17Nee0l029782 for ; Tue, 7 Feb 2006 15:40:40 -0800 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k17Ndrq09062; Tue, 7 Feb 2006 15:39:53 -0800 (PST) Message-ID: <43E92FC2.8000807@isi.edu> Date: Tue, 07 Feb 2006 15:39:46 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Scott Bradner CC: newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure ... References: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> In-Reply-To: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E1A31A688D6FF799F1FB5DD" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E1A31A688D6FF799F1FB5DD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott Bradner wrote: > Spencer opines >> I'm just a lot more comfortable with the idea that anything that gets = >> "reviewed in the IETF" gets "last-called in the IETF", and that anythi= ng=20 >> that doesn't get "last-called in the IETF" would list specific reviewe= rs,=20 >> rather than spreading the credit/blame in all directions. >=20 > I, for 1, fully agree I agree; if the IESG is doing the review for conflicts with IETF WGs, then the IESG should be specifically attributed, not the whole of the IET= F. (contrary to the beliefs of some, the IESG is not the IETF) Joe --------------enig4E1A31A688D6FF799F1FB5DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6S/CE5f5cImnZrsRAmSoAKDv+Lw3q5tkNgMUIhwjlzrVeDIjawCfcDTL uOtELgc32EiD4mWHG/CQQZo= =HjlA -----END PGP SIGNATURE----- --------------enig4E1A31A688D6FF799F1FB5DD-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 07 19:43:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6dQl-0004f2-NS for newtrk-archive@megatron.ietf.org; Tue, 07 Feb 2006 19:43:35 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18340 for ; Tue, 7 Feb 2006 19:41:39 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18AR4XMHO6CWYMqs4p8aiAYTvXdRyrv69I@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k180bxli031220; Tue, 7 Feb 2006 16:37:59 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k180bxDT031219; Tue, 7 Feb 2006 16:37:59 -0800 Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k180bwJ5031202 for ; Tue, 7 Feb 2006 16:37:59 -0800 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc11) with SMTP id <2006020800375301100dmc39e>; Wed, 8 Feb 2006 00:37:53 +0000 Message-ID: <0c9501c62c47$b1237930$3703a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20060207010451.512573C022E@berkshire.machshav.com> <095701c62be7$93d8da60$3703a8c0@china.huawei.com> <3525C4F33C05DFD80A59FBE7@p3.JCK.COM> <43E8CD21.6090306@thinkingcat.com> Subject: Re: [newtrk] "Reviewed in the IETF" Date: Tue, 7 Feb 2006 18:36:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear John, Your assessment of PESCI makes sense to me; I wasn't as close to DKIM but that's what the shouting sounded like in the next room, too. I should mention to the list that Thomas Narten is doing a revision of his I-D on "how to run a successful BOF" (I've seen an interim version, and I like it even better than the 00 version. I'd wait for 01 if I hadn't read 00, but I'd read 01 when it's posted, either way). This draft is descriptive ("this is what has been observed to work"), but no one will be surprised if there are things that get described that we look at and say, "this should work better", so there may be a need for a follow-on document, too. A clarification of BOF mailing lists as design team mailing lists might be very helpful, for example, especially since ADs can now request creation of BOF mailing lists on ietf.org before the BOF request is even approved, and they look a lot like WG mailing lists in the same domain. Thanks, Spencer . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Wed Feb 08 06:14:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nHP-0002Da-Hm for newtrk-archive@megatron.ietf.org; Wed, 08 Feb 2006 06:14:35 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12190 for ; Wed, 8 Feb 2006 06:12:51 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18BX+UcvhPNKivZhdgJ00fk8LAVANQ9qoU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k18BCJ6Y009373; Wed, 8 Feb 2006 03:12:19 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k18BCJKR009372; Wed, 8 Feb 2006 03:12:19 -0800 Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k18BCDEu009367 for ; Wed, 8 Feb 2006 03:12:19 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k18BC7Qk223164 for ; Wed, 8 Feb 2006 11:12:07 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k18BC7KK229056 for ; Wed, 8 Feb 2006 12:12:07 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k18BC6V7008157 for ; Wed, 8 Feb 2006 12:12:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k18BC6Xx008139; Wed, 8 Feb 2006 12:12:06 +0100 Received: from zurich.ibm.com (sig-9-146-218-153.de.ibm.com [9.146.218.153]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA50180; Wed, 8 Feb 2006 12:12:02 +0100 Message-ID: <43E9D201.3030402@zurich.ibm.com> Date: Wed, 08 Feb 2006 12:12:01 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: Scott Bradner , newtrk@lists.uoregon.edu Subject: Re: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure ... References: <20060207131628.EDEDE64DEC8@newdev.harvard.edu> <43E92FC2.8000807@isi.edu> In-Reply-To: <43E92FC2.8000807@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 02:11:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe Touch wrote: > > Scott Bradner wrote: > >>Spencer opines >> >>>I'm just a lot more comfortable with the idea that anything that gets >>>"reviewed in the IETF" gets "last-called in the IETF", and that anything >>>that doesn't get "last-called in the IETF" would list specific reviewers, >>>rather than spreading the credit/blame in all directions. >> >>I, for 1, fully agree > > > I agree; if the IESG is doing the review for conflicts with IETF WGs, > then the IESG should be specifically attributed, not the whole of the IETF. > > (contrary to the beliefs of some, the IESG is not the IETF) No, but its' *in* the IETF. Brian . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 09 20:05:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7MjW-0007JZ-G2 for newtrk-archive@megatron.ietf.org; Thu, 09 Feb 2006 20:05:58 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29057 for ; Thu, 9 Feb 2006 20:04:15 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+j7iSembsN+9fmyE17+9i7WNb1dPq4jr8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A1096U026110; Thu, 9 Feb 2006 17:00:09 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1A109Wc026109; Thu, 9 Feb 2006 17:00:09 -0800 Received: from carter-zimmerman.mit.edu (STRATTON-TWO-SIXTY-EIGHT.MIT.EDU [18.187.6.13]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A108XG026104 for ; Thu, 9 Feb 2006 17:00:09 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BED67E0053; Thu, 9 Feb 2006 20:00:01 -0500 (EST) To: newtrk@lists.uoregon.edu, saag@mit.edu Cc: iesg@ietf.org Subject: [newtrk] BCP 61, advancing to draft From: Sam Hartman Date: Thu, 09 Feb 2006 20:00:01 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Hi. I'd like to remind everyone of BCP 61. It says roughly that protocols we approve need a mandatory to implement security mechanism. We here in the security area think that's a great idea. O, by the way, we're here to help you. As part of our plan for world domination^h^h^hhelping you, we've created a number of security solutions including things like SASL, TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you use these security services instead of inventing your own. First, it makes it hugely easier for us to review your documents. Second, it makes it easier when we need to do algorithm upgrades to things like hash functions or replace DES with AES. Finally it probably makes your security easier to deploy. There's this littple problem though. All of the above are at proposed standard. For a number of reasons they are not moving to draft as soon as anyone would like. So, I see two options that I don't like. First, we can avoid security in anything going to draft. Draft becomes a dumping ground for all the older protocols (plus a few things like SNMP that invent their own security) without updates that add security. Secondly, we can block everything from going to draft. Does anyone want to work on a better answer to this? --Sam . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 04:07:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UFo-0007Mc-7Y for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 04:07:48 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00803 for ; Fri, 10 Feb 2006 04:06:04 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+7xjAnao2dQVzxYvEZucDa2XH+rMBhTJ4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A93abD004042; Fri, 10 Feb 2006 01:03:36 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1A93akH004041; Fri, 10 Feb 2006 01:03:36 -0800 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A93ZtK004036 for ; Fri, 10 Feb 2006 01:03:36 -0800 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73359259747; Fri, 10 Feb 2006 10:02:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26029-05; Fri, 10 Feb 2006 10:02:11 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DA4A25976F; Fri, 10 Feb 2006 10:02:08 +0100 (CET) Date: Fri, 10 Feb 2006 10:02:54 +0100 From: Harald Tveit Alvestrand To: Sam Hartman , newtrk@lists.uoregon.edu, saag@MIT.EDU Cc: iesg@ietf.org Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Message-ID: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========955C3E105A2374299B40==========" X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: by amavisd-new at alvestrand.no X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk --==========955C3E105A2374299B40========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 9. februar 2006 20:00 -0500 Sam Hartman wrote: > As part of our plan for world domination^h^h^hhelping you, we've > created a number of security solutions including things like SASL, > TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you > use these security services instead of inventing your own. First, it > makes it hugely easier for us to review your documents. Second, it > makes it easier when we need to do algorithm upgrades to things like > hash functions or replace DES with AES. Finally it probably makes > your security easier to deploy. > > > There's this littple problem though. All of the above are at proposed > standard. > > For a number of reasons they are not moving to draft as soon as anyone > would like. Care to elaborate? > So, I see two options that I don't like. First, we can avoid security > in anything going to draft. Draft becomes a dumping ground for all > the older protocols (plus a few things like SNMP that invent their own > security) without updates that add security. Secondly, we can block > everything from going to draft. > > Does anyone want to work on a better answer to this? Seems that there are two possible answers: - Move the security stuff to Draft (knocking down the reasons for that not=20 happening one at a time, possibly changing the criteria for Draft on the=20 way) - Abolish Draft I consider the third option - having Draft with downreference to Proposed - = to be a Bad Idea. If we have to do that, I'd rather abandon Draft. Harald --==========955C3E105A2374299B40========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD7Fa+OMj+2+WY0F4RAm+VAKD8gDap4F3rpFzL3H8yQmz/iPp1fQCdEEiC DxD+ZLhI5VvtRpkn3Jgmc0o= =TxYc -----END PGP SIGNATURE----- --==========955C3E105A2374299B40==========-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 04:43:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UoV-0004zb-Cy for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 04:43:39 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03712 for ; Fri, 10 Feb 2006 04:41:55 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/o73l7HRWr6AoZoJDy1jUf2hwliRyIp5Q@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A9fW0S004550; Fri, 10 Feb 2006 01:41:32 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1A9fWQp004549; Fri, 10 Feb 2006 01:41:32 -0800 Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1A9fPtN004537 for ; Fri, 10 Feb 2006 01:41:31 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1A9fJQk044212 for ; Fri, 10 Feb 2006 09:41:19 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1A9fKC3237592 for ; Fri, 10 Feb 2006 10:41:20 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1A9fJN1005112 for ; Fri, 10 Feb 2006 10:41:19 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1A9fIgx005097; Fri, 10 Feb 2006 10:41:19 +0100 Received: from zurich.ibm.com (sig-9-145-253-49.de.ibm.com [9.145.253.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA44602; Fri, 10 Feb 2006 10:41:15 +0100 Message-ID: <43EC5FB0.4040404@zurich.ibm.com> Date: Fri, 10 Feb 2006 10:41:04 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Sam Hartman CC: newtrk@lists.uoregon.edu Subject: [newtrk] Re: BCP 61, advancing to draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit (cc's stripped, AD hat off). > Does anyone want to work on a better answer to this? Yes. draft-carpenter-newtrk-twostep or draft-loughney-newtrk-one-size-fits-all Brian Sam Hartman wrote: > > Hi. I'd like to remind everyone of BCP 61. It says roughly that > protocols we approve need a mandatory to implement security mechanism. > We here in the security area think that's a great idea. O, by the > way, we're here to help you. > > As part of our plan for world domination^h^h^hhelping you, we've > created a number of security solutions including things like SASL, > TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you > use these security services instead of inventing your own. First, it > makes it hugely easier for us to review your documents. Second, it > makes it easier when we need to do algorithm upgrades to things like > hash functions or replace DES with AES. Finally it probably makes > your security easier to deploy. > > > There's this littple problem though. All of the above are at proposed > standard. > > For a number of reasons they are not moving to draft as soon as anyone > would like. > > > So, I see two options that I don't like. First, we can avoid security > in anything going to draft. Draft becomes a dumping ground for all > the older protocols (plus a few things like SNMP that invent their own > security) without updates that add security. Secondly, we can block > everything from going to draft. > > Does anyone want to work on a better answer to this? > > --Sam > > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 07:41:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XaM-0003QA-Eq for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 07:41:14 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15826 for ; Fri, 10 Feb 2006 07:39:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19KcoIZio7ulAaJGsVHDDx9r8kkWzrC2ZY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ACYfoD007444; Fri, 10 Feb 2006 04:34:41 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1ACYfHQ007443; Fri, 10 Feb 2006 04:34:41 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ACYe2v007438 for ; Fri, 10 Feb 2006 04:34:40 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 01707E0053; Fri, 10 Feb 2006 07:34:33 -0500 (EST) To: Harald Tveit Alvestrand Cc: newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org Subject: [newtrk] Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> From: Sam Hartman Date: Fri, 10 Feb 2006 07:34:33 -0500 In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Fri, 10 Feb 2006 10:02:54 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "Harald" == Harald Tveit Alvestrand writes: >> >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? Sure, but this is very much with my AD hat off and with the warning that I'm probably wrong on some of these. SASL: internationalization issues; low number of volunteers dedicating time. Not clear which mechanism to move to draft to validate the framework. IPsec: just moved to proposed again; not many implementations; already needs for clarifications drafts. TLS: Moving to proposed again because of hash mess. Kerberos: Doable, but we're all fairly busy working on meeting new customer needs. We did recently hold a meeting and develop feature matrix and roughly what we'd need to remove from the spec. We were really hoping that RFC 4120 would not need things removed; I think a lot of us lost interest in moving Kerberos to draft any time soon when we found out that was not the case. GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism depends on Kerberos. Everything else needs some significant work on the documentation front that no one is really chartered to do. An individual wanted to do the work and was encouraged to contact an AD when they had a draft; haven't heard from them in months. PKIX: I think has some internationalization issues; possibly some hash fun. Not really sure. CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this was in the best shape. --Sam . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 09:13:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z1J-0002DG-7G for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:13:09 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22159 for ; Fri, 10 Feb 2006 09:11:25 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/GIiyPZfvgBjZX6J4He2ykGdobEYW4ceM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEAItp008879; Fri, 10 Feb 2006 06:10:18 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AEAIMT008878; Fri, 10 Feb 2006 06:10:18 -0800 Received: from eastrmmtao03.cox.net (eastrmmtao03.cox.net [68.230.240.36]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AD6YHx007859 for ; Fri, 10 Feb 2006 05:06:35 -0800 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210130631.MVZI29285.eastrmmtao03.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 08:06:31 -0500 In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> Cc: Sam Hartman , newtrk@lists.uoregon.edu, saag@MIT.EDU, iesg@ietf.org Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 08:06:27 -0500 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 04:02, Harald Tveit Alvestrand wrote: % Seems that there are two possible answers: % % - Move the security stuff to Draft (knocking down the reasons for that % not happening one at a time, possibly changing the criteria for Draft % on the way) % - Abolish Draft % % I consider the third option - having Draft with downreference to Proposed - % to be a Bad Idea. If we have to do that, I'd rather abandon Draft. I would suggest that in parallel both (1) "move the security stuff to Draft" and (2) "abolish Draft Standard" of Harald's suggestions be undertaken. My guess is that Sam's note was a polite way of trying to "encourage" the security community to undertake (1), but I could be wrong. Security is not the only thing that impedes going to Draft Standard or Full Standard. There is a longish list of things that can impede progression away from Proposed Standard. We have an impressive number of IETF standards-track protocols that have been at Proposed Standard for many many years. Some are widely used, while others are widely ignored. My proposal for a new standards track looks roughly like this: 1) Proposed Standard - Rules exactly as they are to progress to Proposed Standard - No Changes 2) Delete the "Draft Standard" state, but keep the "multiple interoperable implementations" rule and apply that rule to "Full Standard". 3) Require that most Proposed Standards (i.e. those that are not blocked by the failure of some other standard to advance) move to Full Standard within 2 years (edit time to your taste) of publication as a Proposed Standard or 2 years of all normative references moving to Full Standard, whichever comes later. Anything that does not meet that requirement automatically gets reclassified as HISTORIC status unless the IESG grants an exception at the 2 year timeout. IESG exceptions are themselves limited to 2 years. Any IESG exception requires the IESG to publicly say why the exception was granted in the particular case. 4) 3 months after the above changes are approved, any documents already at Draft Standard progress automatically to Full Standard, unless the IESG takes some other action (e.g. move to Historic) on the Draft Standard(s) during the 3 month window just after the process changes are approved. This achieves the following goals: (1) simplifies the standards track greatly, which by itself increases the incentive to advance a document, and (in theory) reduces the workload for the IESG. (2) retains the requirement for demonstrated interoperability before becoming a Full Standard. We all understand why this is important. (3) creates a "timeout" that incents WGs and individuals to progress their documents all the way along to Full Standard, lest the document(s) automatically move to HISTORIC. This timeout period does not start until the document is unblocked by normative references. (4) gives the IESG the power to grant exceptions to the "timeout" for any exceptional cases. Yours, Ran rja@extremenetworks.com . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 09:13:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z1y-0002tk-S4 for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:13:50 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22260 for ; Fri, 10 Feb 2006 09:11:59 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19D2A3CZgH+LnDbI4GJ6BRjWPkRP5yxJwE@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEBjQu008930; Fri, 10 Feb 2006 06:11:46 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AEBjoW008929; Fri, 10 Feb 2006 06:11:45 -0800 Received: from harpo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ADXLKe008373 for ; Fri, 10 Feb 2006 05:33:22 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 79EEC34ADD; Sat, 11 Feb 2006 02:33:16 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16797-28; Sat, 11 Feb 2006 02:33:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id BCB0334ACD; Sat, 11 Feb 2006 02:33:15 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 606BD37748; Sat, 11 Feb 2006 02:33:15 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F7YOq-00057E-00; Sat, 11 Feb 2006 02:33:24 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: rja@extremenetworks.com, saag@mit.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: iesg@ietf.org, newtrk@lists.uoregon.edu In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-Id: Date: Sat, 11 Feb 2006 02:33:24 +1300 X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk RJ Atkinson writes: >> PKIX: I think has some internationalization issues; possibly some hash >> fun. Not really sure. >> >> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >> was in the best shape. > >These also don't look like low-hanging fruit. > >I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >tree just now. And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is what held up TLS at the RFC 2246 stage for what, three years?). Presumably IPsec will also block on PKIX. This is why I proposed the relative- rather than absolute-value reference approach in my previous message. Without this, you get the priority-inversion situation of the lowest-hanging fruit stalled behind the highest-hanging fruit (not to mention appallingly mangled metaphors). Peter. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 09:16:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z4K-0004uA-Mq for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:16:16 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22524 for ; Fri, 10 Feb 2006 09:14:33 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19m47gw+EvsfqiZioqCBuzjW+hUhjvTDHk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEAjb3008893; Fri, 10 Feb 2006 06:10:45 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AEAjsC008892; Fri, 10 Feb 2006 06:10:45 -0800 Received: from harpo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ADDuZm007970 for ; Fri, 10 Feb 2006 05:13:56 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id B339E34B65; Sat, 11 Feb 2006 02:13:07 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31021-29; Sat, 11 Feb 2006 02:13:07 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 0802834685; Sat, 11 Feb 2006 02:13:06 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 03A7D37748; Sat, 11 Feb 2006 02:13:06 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F7Y5L-00055F-00; Sat, 11 Feb 2006 02:13:15 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: harald@alvestrand.no, hartmans-ietf@MIT.EDU Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, saag@MIT.EDU In-Reply-To: Message-Id: Date: Sat, 11 Feb 2006 02:13:15 +1300 X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Sam Hartman writes: >>>>>> "Harald" == Harald Tveit Alvestrand writes: > >> > >> For a number of reasons they are not moving to draft as soon as > >> anyone would like. > > Harald> Care to elaborate? > >Sure, but this is very much with my AD hat off and with the warning that I'm >probably wrong on some of these. > >[List snipped] Just looking at this list, is the document-status thing just a case of changing some policy, or is there more to it than that? For example from that list TLS, Kerberos, and CMS have all been around for 10-15 years so it's unlikely that there are going to be major changes in the spec, and in particular that there will be non-backwards-compatible changes. So all you'd need to do is instead of pointing to [RFCxxxx], point to [TLS], where [TLS] is "'The TLS Protocol', version 1.1 or any later version". This is already done by documents like the GPL, which specify use of "version X or any later version" rather than hardcoding in a particular document. Since these protocols stick around for years, even decades (I mean we've only just got around to deprecating the broken SSLv2 protocol after 12 years of use), I can't see any major interop problems turning up. Without this, you end up with horrible priority inversions where some far-distant unfinished spec ends up blocking a major standards effort that needs to refer to it. Peter. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 09:16:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z4q-0005Mx-NJ for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:16:48 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22585 for ; Fri, 10 Feb 2006 09:14:57 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+HjLVCYUcExQsjgwqoqmgrQiWV9FLZh5A@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEB5Sc008905; Fri, 10 Feb 2006 06:11:05 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AEB5pi008904; Fri, 10 Feb 2006 06:11:05 -0800 Received: from eastrmmtao02.cox.net (eastrmmtao02.cox.net [68.230.240.37]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ADLN7s008236 for ; Fri, 10 Feb 2006 05:21:23 -0800 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210132120.STUB14821.eastrmmtao02.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 08:21:20 -0500 In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Cc: newtrk@lists.uoregon.edu, iesg@ietf.org Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 08:21:16 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 07:34, Sam Hartman wrote: > Sure, but this is very much with my AD hat off and with the warning > that I'm probably wrong on some of these. > > SASL: internationalization issues; low number of volunteers dedicating > time. Not clear which mechanism to move to draft to validate the > framework. So the issue here is multiple-dependency: - SASL can't advance because of the I18N rules - lots of other stuff can't advance because of SASL I'd say that the thing to do is to waive the I18N rule to let SASL go to Draft (with a requirement that I18N issues get addressed before further forward motion) -- then push on the I18N portion of the IETF to pitch in on this. I'm familiar with several languages and from time to time (e.g. MIME) have been involved in I18N discussions in the IETF. However, a big percentage of the IETF are only familiar with one or two languages (polyglots are actually rare in our circles). Those familiar with only one language are not likely to be able to help very much. > IPsec: just moved to proposed again; not many implementations; already > needs for clarifications drafts. One only needs 2 interoperable implementations to move to Draft Standard. If the new spec(s) don't have that, push the implementers to sort out interoperability, find 2 that work, declare victory, and move to Draft. If our current process had been around when TCP was first being specified, implemented, and tested, TCP would have become totally wedged also, IMHO. > TLS: Moving to proposed again because of hash mess. I'd suggest pushing on this one first in a focused way. The hash situation should be very straight-forward to sort out, if the ADs apply time pressure to the group. Adding new hash functions is not technically difficult, though IETF processes can be very difficult these days. > Kerberos: Doable, but we're all fairly busy working on meeting new > customer needs. We did recently hold a meeting and develop feature > matrix and roughly what we'd need to remove from the spec. We were > really hoping that RFC 4120 would not need things removed; I think a > lot of us lost interest in moving Kerberos to draft any time soon when > we found out that was not the case. If the issue is that not all features of 4120 are in at least 2 implementations, there are a couple of approaches. One is to go find a sponsor to fund someone to add the missing feature(s) to either MIT Kerberos or Heimdal. The other is to do what OSPF did with M-OSPF, move the not yet widely implemented (but perceived useful) items into a separate document so the main spec can advance more quickly. (Aside: I still miss having M-OSPF. It worked very well and was very easy to configure and operate. PIM has never come close to being as useful as M-OSPF. Sigh) > GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism > depends on Kerberos. Everything else needs some significant work on > the documentation front that no one is really chartered to do. An > individual wanted to do the work and was encouraged to contact an AD > when they had a draft; haven't heard from them in months. Given that analysis, this is probably not low hanging fruit. > PKIX: I think has some internationalization issues; possibly some hash > fun. Not really sure. > > CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this > was in the best shape. These also don't look like low-hanging fruit. I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the tree just now. Just as I believe the security-interested people in the IETF need to pitch in to help other areas advance their specs, I also believe the I18N- interested people in the IETF need to help the security specs so the security area can advance its specs. We are all in this together. Yours, Ran rja@extremenetworks.com . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 09:16:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z4p-0005Mp-7B for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:16:49 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22580 for ; Fri, 10 Feb 2006 09:14:54 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX188z1sixAGPne6Pb2ZNdPRl8p961TEfWJM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEBRU1008917; Fri, 10 Feb 2006 06:11:27 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AEBRco008916; Fri, 10 Feb 2006 06:11:27 -0800 Received: from machshav.com (machshav.com [147.28.0.16]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ADTfUG008345 for ; Fri, 10 Feb 2006 05:29:41 -0800 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED416FB2A0; Fri, 10 Feb 2006 08:29:40 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 6C43D3BFDED; Fri, 10 Feb 2006 08:29:40 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: RJ Atkinson Cc: saag@mit.edu, iesg@ietf.org, newtrk@lists.uoregon.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: (Your message of "Fri, 10 Feb 2006 08:21:16 EST.") <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Feb 2006 08:29:40 -0500 Message-Id: <20060210132940.6C43D3BFDED@berkshire.machshav.com> X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk In message <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com>, RJ Atkin son writes: > > > >> TLS: Moving to proposed again because of hash mess. > >I'd suggest pushing on this one first in a focused way. The hash >situation should be very straight-forward to sort out, if the ADs >apply time pressure to the group. Adding new hash functions is >not technically difficult, though IETF processes can be very difficult >these days. The issue is not adding the hash functions, it's adding the negotiation to permit their use. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 10:24:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7a8P-00044X-MJ for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 10:24:35 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27534 for ; Fri, 10 Feb 2006 10:22:41 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX188sRQHE9te2vS+IIs/Wt54szVK0seQSZk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AFKwDW010207; Fri, 10 Feb 2006 07:20:58 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AFKwNb010206; Fri, 10 Feb 2006 07:20:58 -0800 Received: from boole.openldap.org (root@boole.openldap.org [204.152.186.50]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AFKv7o010201 for ; Fri, 10 Feb 2006 07:20:58 -0800 Received: from gyspy.OpenLDAP.org ([12.168.234.3]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1AFKfOM002622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2006 15:20:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060210070911.03a20128@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 10 Feb 2006 07:20:37 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk I note that just because some dependencies are not yet ready to be progressed to Draft Standard doesn't preclude us from revising protocols as needed to address other issues holding them at Proposed. For instance, with LDAP, we've resolved a host of issues requiring publication of revised LDAP specifications. These will get published at Proposed in conjunction with revised TLS and SASL specs, then pending implementation reports and other requirements, we should get to Draft. I also note that the formal Draft Standard declaration is not nearly as important as resolution of the technical issues that kept us at Proposed. As these issues have been adequately addressed, I'm quite happy. The formalities will catch up in due course. That is, I really don't see a problem here. Kurt At 05:00 PM 2/9/2006, Sam Hartman wrote: >Hi. I'd like to remind everyone of BCP 61. It says roughly that >protocols we approve need a mandatory to implement security mechanism. >We here in the security area think that's a great idea. O, by the >way, we're here to help you. > >As part of our plan for world domination^h^h^hhelping you, we've >created a number of security solutions including things like SASL, >TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you >use these security services instead of inventing your own. First, it >makes it hugely easier for us to review your documents. Second, it >makes it easier when we need to do algorithm upgrades to things like >hash functions or replace DES with AES. Finally it probably makes >your security easier to deploy. > > >There's this littple problem though. All of the above are at proposed >standard. > >For a number of reasons they are not moving to draft as soon as anyone >would like. > > >So, I see two options that I don't like. First, we can avoid security >in anything going to draft. Draft becomes a dumping ground for all >the older protocols (plus a few things like SNMP that invent their own >security) without updates that add security. Secondly, we can block >everything from going to draft. > >Does anyone want to work on a better answer to this? > >--Sam > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 11:14:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7auK-0005SC-Qd for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 11:14:08 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03308 for ; Fri, 10 Feb 2006 11:12:12 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19o0hqKrwjl0Dfq5q+2osczpUodqry9hJI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AG3Ymf011007; Fri, 10 Feb 2006 08:03:34 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AG3YrY011006; Fri, 10 Feb 2006 08:03:34 -0800 Received: from yxa.extundo.com (root@178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AEuQZ6009672 for ; Fri, 10 Feb 2006 06:56:27 -0800 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k1AEu2u9027180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2006 15:56:02 +0100 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, rja@extremenetworks.com, saag@mit.edu Subject: [newtrk] Re: BCP 61, advancing to draft References: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060210:rja@extremenetworks.com::BVSKOVen/igG+Oge:q0e X-Hashcash: 1:21:060210:newtrk@lists.uoregon.edu::VJjTfhuDoD+gafBL:02SN X-Hashcash: 1:21:060210:iesg@ietf.org::36uWFhv8FQQOygdC:29a2 X-Hashcash: 1:21:060210:saag@mit.edu::JZTCsHHBf+Gb0MF/:AHsr X-Hashcash: 1:21:060210:pgut001@cs.auckland.ac.nz::7sGnQKDLJ+ddF4X2:Rzhn Date: Fri, 10 Feb 2006 15:56:01 +0100 In-Reply-To: (Peter Gutmann's message of "Sat, 11 Feb 2006 02:33:24 +1300") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > RJ Atkinson writes: >>> PKIX: I think has some internationalization issues; possibly some hash >>> fun. Not really sure. >>> >>> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >>> was in the best shape. >> >>These also don't look like low-hanging fruit. >> >>I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >>SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >>tree just now. > > And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). Presumably > IPsec will also block on PKIX. This is why I proposed the relative- rather > than absolute-value reference approach in my previous message. Without this, > you get the priority-inversion situation of the lowest-hanging fruit stalled > behind the highest-hanging fruit (not to mention appallingly mangled > metaphors). I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and TLS-OpenPGP. Decoupling TLS from PKIX fully would be a good idea. It would also help non-PKIX TLS mechanisms, which is also good. OTOH, to abolish draft seem like a better approach to me. The market doesn't seem to care if a document is at proposed or draft. The technical quality isn't better at higher standards level either. Just look at DNS. The only people who seem to care about this separation is long time IETF attendees, but they seem to have few instruments available to apply pressure on others to write standards. To make somebody write a standard, there should be some incentive or at least some good reason for doing the work. It is not a compelling reason to ask "Well, don't you want this document as Draft?". I'm not sure I see any real reason for spending the time on moving, say, IPSEC from proposed to draft. For most organizations, it seems the time is better spent on improving implementations (which will result in improvements to the standard too, eventually). Thanks, Simon . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 11:40:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bKB-0003Py-ML for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 11:40:47 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06221 for ; Fri, 10 Feb 2006 11:39:02 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/K+u9r61apySt3ycruwK9mF5XqwEcFXvk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGcrf9011972; Fri, 10 Feb 2006 08:38:53 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGcr5J011971; Fri, 10 Feb 2006 08:38:53 -0800 Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGcrU7011966 for ; Fri, 10 Feb 2006 08:38:53 -0800 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc11) with SMTP id <20060210163847m1100bvl32e>; Fri, 10 Feb 2006 16:38:47 +0000 Message-ID: <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: Cc: "\"RJ Atkinson\"" References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 10:37:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Trimming down to Newtrk plus Ran (I don't know if Ran is on Newtrk, but all of the other process-ish discussants are - and Ran, please take this as a compliment, because it means you may have been doing real work :-)... > 1) Proposed Standard > - Rules exactly as they are to progress to Proposed Standard > - No Changes > 2) Delete the "Draft Standard" state, but keep the "multiple > interoperable > implementations" rule and apply that rule to "Full Standard". There have been several two-stage suggestions previously, and I liked most of them, so I like Ran's particular variant, certainly as a starting point. > 3) Require that most Proposed Standards (i.e. those that are not blocked > by the failure of some other standard to advance) move to Full > Standard within 2 years (edit time to your taste) of publication > as a Proposed Standard or 2 years of all normative references > moving to Full Standard, whichever comes later. Anything that > does not meet that requirement automatically gets reclassified > as HISTORIC status unless the IESG grants an exception at the > 2 year timeout. IESG exceptions are themselves limited to 2 years. > Any IESG exception requires the IESG to publicly say why the > exception was granted in the particular case. I have two comments here. One is that any time we have made noises like "gee, how 'bout we actually do what RFC 2026, and RFC 1620 before that, and RFC 1310 before that, say we're going to do, and bail all the old Proposed Standards to Historic if there's no energy to advance them", total panic has broken out. Let me be very clear. We have never had time to do what our standards process says we do, except in exceptional cases. Extrapolating from roughly March 1992, I'm guessing that we never will. Proposals that assume a 90-degree turn need to explain the physics that result in that turn. I happen to like where Ran is headed, because I think (sighting along the top of his head forward), we would be headed to a place were we don't have as many active standards-track documents - but the ones we have, are the ones that we care about. For me personally, the DeCruft work was depressing because the criteria seemed to be, "well, if this RFC was FTPed over a satellite link, we have to make sure that 'no one on another planet might have been eavesdropping and might now be thinking about planning to use it' before we can move it to Historic". "No energy" means "no standard", given a certain amount of time. Doesn't make the documents vaportize, just tells the rest of the world that this once-Proposed Standard is getting no attention from anyone, so should realistically be "use at own risk". Just FWIW, I'm not sure that the reclassification needs to be an IESG responsibility - we've had 13(ish) ADs put these protocols on the standards track, knowing full well that many of these protocols will be implemented and widely deployed; does it take 13 ADs to say, "well, maybe this document should advance"? Since the alternative seems to be encouraging people to pay no attention at all to standards maturity levels, perhaps "seems mostly harmless" would be an acceptable reason for an exception. But that's a side issue. Second - and this is a way-detailed comment on Ran's proposal - I happened to notice http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from another standards organization; their algorithm is "gotta look at every standard every five years and pick of (1) reaffirm, (2) revise, or (3) withdraw". We've sorta/kinda done the pass looking at the Proposed Standards that we wanted to withdraw. If we made another pass saying, "these are the ones we want to reaffirm; we think they are OK for advancement", we might be pretty close to what (I understood) Ran was proposing. And if the first-pass number was three years, and the extension was two years, that would give us the same horizon IEEE 802 uses (which doesn't make it right, but doesn't make it wrong, either). Thanks, Spencer . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 11:43:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bN4-0004Gl-EZ for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 11:43:46 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06488 for ; Fri, 10 Feb 2006 11:42:02 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19hgnt88BBlJKpx22+8zuJ+0wCTA0BqCHU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGcL3H011958; Fri, 10 Feb 2006 08:38:21 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGcLQQ011957; Fri, 10 Feb 2006 08:38:21 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGcF8A011952 for ; Fri, 10 Feb 2006 08:38:15 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F7bHV-000Ghg-Tl; Fri, 10 Feb 2006 11:38:02 -0500 Date: Fri, 10 Feb 2006 11:38:01 -0500 From: John C Klensin To: Brian E Carpenter cc: Sam Hartman , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Re: BCP 61, advancing to draft Message-ID: <7F378285C91B986C0B7EEA02@p3.JCK.COM> In-Reply-To: <43EC5FB0.4040404@zurich.ibm.com> References: <43EC5FB0.4040404@zurich.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 10 February, 2006 10:41 +0100 Brian E Carpenter wrote: > (cc's stripped, AD hat off). > > > Does anyone want to work on a better answer to this? > > Yes. draft-carpenter-newtrk-twostep or > draft-loughney-newtrk-one-size-fits-all > > Brian Or draft-ietf-newtrk-repurposing-isd With explicit qualifying language about these cases (not just a downref, about which I agree with Harald). I don't see "twostep" as being helpful to this problem, since there would still be a downref problem. or, if we can't solve this problem (for some plausible value of "solve" without abandoning a multi-stage process, the hypothetical draft-(hypothetical)-merger-ISO/IEC-JTC1/SCnn More seriously, I continue to favor a rule that says that, if someone has achieved wide deployment and interoperability demonstrated in production implementations, we should write up any concerns we have about the thing and then move the whole business, list of concerns and all, directly to full standard. It seems to me that we need to remember that, whether we have one standards maturity level, or two or three or four, those levels are tied to maturity of definition and interoperable implementations, not to whether we recommend the thing. We still have "required/ recommended/ not recommended" in our traditions somewhere, in spite of never assigning them any more. One inference to be drawn from Sam's note is that we are beginning to resemble a slapstick act: first we find a large block and call it a "rule", then we put it in front of ourselves, and then we trip over it and fall down. Let's take TLS as an example. No one serious can make a case that it is not widely deployed, or that there are not multiple implementations, or that those implementations are not interoperable. So it depends on some externalities that are not resolved in a way that we'd consider optimal (such as a good PKI structure) and we don't have completely satisfactory ways of dealing with some issues. So... document those observations as risks, warn people that they should be aware of problems that might occur in the future and that they should watch for an improved "version N+1". Then get it out there and put this to rest. The reality is that, if anyone really waited for things to meet the IETF's current rules for full standards, we'd be running telnet, FTP, email, and little else on the network -- at least until someone deprecated them for not meeting those standards. john p.s. FWIW, part of the original motivation for ISDs was to provide a framework for developing and implementing this sort of "document it and move on" approach. That, and other things, got lost in arguments about how much text belonged where, how much work the IESG wanted to do, etc. I lay good odds that if the security area wants to block anything from moving to Draft unless all of the relevant security protocols ducks have been lined up and marched to Draft under the current rules, the discussion of that will waste significantly more time. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 11:46:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bQ0-00062v-SC for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 11:46:48 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06675 for ; Fri, 10 Feb 2006 11:45:04 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX181q7VDGcXqWrFHfWiU4bzNrRJPjhbdiNM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGinf8012084; Fri, 10 Feb 2006 08:44:49 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGinKK012083; Fri, 10 Feb 2006 08:44:49 -0800 Received: from above.proper.com (above.proper.com [208.184.76.39]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AF2SVh009768 for ; Fri, 10 Feb 2006 07:02:28 -0800 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1AF2DPG090755; Fri, 10 Feb 2006 07:02:16 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Date: Fri, 10 Feb 2006 06:52:33 -0800 To: Harald Tveit Alvestrand , Sam Hartman , newtrk@lists.uoregon.edu, saag@mit.edu From: Paul Hoffman Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk One big issue we have with security protocols moving to draft is that there is very little volunteer interest in testing SHOULD/MUST interop beyond the basics (if even that). Our protocols have a lot of SHOULDs that have nothing to do with interop and are very difficult to test. But, even without those, the security area has been much less active at voluntary interop testing than other areas, which makes "going to Draft" not appealing. We are generally happy to cycle at Proposed. Sam's message points out a significant ramification of that attitude, although I don't have a proposed solution to the problem. --Paul Hoffman, Director --VPN Consortium . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 11:53:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bWs-0000j9-M8 for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 11:53:55 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07240 for ; Fri, 10 Feb 2006 11:52:10 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+LjOKczcOpHX3maU62/7kMgdmErm3MhmI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGn35M012248; Fri, 10 Feb 2006 08:49:03 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGn31r012247; Fri, 10 Feb 2006 08:49:03 -0800 Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AE8Xh8008846 for ; Fri, 10 Feb 2006 06:08:33 -0800 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210140830.TTHL4894.eastrmmtao01.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 09:08:30 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Cc: saag@mit.edu, iesg@ietf.org, newtrk@lists.uoregon.edu Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 09:08:26 -0500 To: Peter Gutmann X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 08:33, Peter Gutmann wrote: > And that's the problem - CMS and TLS are both blocked waiting on > PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). > Presumably IPsec will also block on PKIX. ESP/AH do not depend on PKIX, and they ought not normatively depend on IKE (or any other automatic key management method), so ESP/AH should be able to move forward without PKIX. Similarly, applications that use ESP/AH, should be able to move forward when ESP/AH move forward, regardless of IKE (or PKIX). The modular design of ESP/AH/ISAKMP/IKE was very deliberate -- because the original designer of ESP/AH fully expected that the key management schemes would need to change (given the past history of Diffie-Hellman and Needham-Schroder in the published history up through 1995). Cheers, Ran . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 12:01:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bdw-0002CU-7o for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 12:01:12 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07767 for ; Fri, 10 Feb 2006 11:59:27 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+r4HVjc1me8i6FlVGz7OmHygbpy4i7Ycc@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGqgGn012312; Fri, 10 Feb 2006 08:52:42 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGqgQx012311; Fri, 10 Feb 2006 08:52:42 -0800 Received: from smtp.uoregon.edu (mserv4 [128.223.142.54]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGqf0U012306 for ; Fri, 10 Feb 2006 08:52:41 -0800 Received: from uoregon.edu (geoduck [128.223.142.113]) by smtp.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGqYGX015033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Feb 2006 08:52:34 -0800 Received: from localhost (llynch@localhost) by uoregon.edu (8.13.1/8.13.1/Submit) with ESMTP id k1AGqXYO016351; Fri, 10 Feb 2006 08:52:33 -0800 X-Authentication-Warning: geoduck.uoregon.edu: llynch owned process doing -bs Date: Fri, 10 Feb 2006 08:52:33 -0800 (PST) From: "Lucy E. Lynch" X-X-Sender: llynch@geoduck.uoregon.edu To: Spencer Dawkins cc: newtrk@lists.uoregon.edu, "\\\"RJ Atkinson\\\"" Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> Message-ID: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mserv4 X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk On Fri, 10 Feb 2006, Spencer Dawkins wrote: > Trimming down to Newtrk plus Ran (I don't know if Ran is on Newtrk, but all > of the other process-ish discussants are - and Ran, please take this as a > compliment, because it means you may have been doing real work :-)... list admin note - the following names were added to secondary posting this am to save wear and tear on your truely: rja@extremenetworks.com pgut001@cs.auckland.ac.nz smb@cs.columbia.edu paul.hoffman@vpnc.org This means they can post, but won't see list traffic (at those addresses). . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 12:05:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bhm-0002hC-MB for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 12:05:14 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08005 for ; Fri, 10 Feb 2006 12:03:18 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/yYcnMkwx/NQWPfUk0TYXMB8DRXLIuWtA@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGx1hS012471; Fri, 10 Feb 2006 08:59:01 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AGx1b5012470; Fri, 10 Feb 2006 08:59:01 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AGx0fV012465 for ; Fri, 10 Feb 2006 08:59:00 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F7bbn-000Gjk-Ib; Fri, 10 Feb 2006 11:59:00 -0500 Date: Fri, 10 Feb 2006 11:58:58 -0500 From: John C Klensin To: Spencer Dawkins , newtrk@lists.uoregon.edu cc: "\\RJ Atkinson\\" Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft Message-ID: <065B369BE79ACFDBD63CD76D@p3.JCK.COM> In-Reply-To: <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 10 February, 2006 10:37 -0600 Spencer Dawkins wrote: >... > Second - and this is a way-detailed comment on Ran's proposal > - I happened to notice > http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from > another standards organization; their algorithm is "gotta look > at every standard every five years and pick of (1) reaffirm, > (2) revise, or (3) withdraw". We've sorta/kinda done the pass > looking at the Proposed Standards that we wanted to withdraw. > If we made another pass saying, "these are the ones we want to > reaffirm; we think they are OK for advancement", we might be > pretty close to what (I understood) Ran was proposing. And if > the first-pass number was three years, and the extension was > two years, that would give us the same horizon IEEE 802 uses > (which doesn't make it right, but doesn't make it wrong, > either). The "five year rule" is one that ANSI imposes on all of its accredited SDOs. While it has some advantages, it has observably had a few side effects. First, in encourages keeping what we call WGs around forever to maintain (and develop new versions of) documents. Second, those semi-permanent WGs tend to develop feature-creep, and bad second- and third- and fourth-system effects to justify their continued existence (and perhaps fine lunches and dinners)... any standard can be made "better" by adding a few additional features, right? Sometimes that process produces strict forward compatibility, sometimes it doesn't, but it often does not yield the kind of extreme protocol compatibility over time on which the Internet depends. To use a favorite example that Ned Freed and I often cite, the relationship between X.400(84) and X.400(88) --in which communication between the two versions could occur only via gateways and often with some information loss-- would be difficult or impossible to develop in the IETF. In ISO (and ANSI SDOs and the ITU-T) it is, demonstrably, fairly easy. So be a bit careful what you wish for here. john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 12:44:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7cKE-0004ub-4m for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 12:44:56 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11537 for ; Fri, 10 Feb 2006 12:42:59 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+yrPicab2TRyqFOK8uyKyGy4FreGVRq5E@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AHY57H013428; Fri, 10 Feb 2006 09:34:05 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AHY5Eq013427; Fri, 10 Feb 2006 09:34:05 -0800 Received: from exprod6og13.obsmtp.com (exprod6og13.obsmtp.com [64.18.1.25]) by mailapps.uoregon.edu (8.13.5/8.13.5) with SMTP id k1AHY5pe013422 for ; Fri, 10 Feb 2006 09:34:05 -0800 Received: from source ([192.150.11.134]) by exprod6ob13.obsmtp.com ([64.18.5.12]) with SMTP; Fri, 10 Feb 2006 09:34:05 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k1AHXWBl017553 for ; Fri, 10 Feb 2006 09:33:33 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k1AHY2rs023066 for ; Fri, 10 Feb 2006 09:34:03 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUH00DKYFGQVJ@mailsj-v1.corp.adobe.com> for newtrk@lists.uoregon.edu; Fri, 10 Feb 2006 09:34:02 -0800 (PST) Received: from MasinterT43p ([10.7.240.49]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUH00HEPFGPDM@mailsj-v1.corp.adobe.com> for newtrk@lists.uoregon.edu; Fri, 10 Feb 2006 09:34:01 -0800 (PST) Date: Fri, 10 Feb 2006 09:34:03 -0800 From: Larry Masinter Subject: [newtrk] interoperability reports: add security mechanism reporting? To: "'New Track'" Message-id: <000e01c62e68$2fa8b5a0$31f0070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcYuaC9ZUAfuzERoTPuiLmohTgKHHA== X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > Hi. I'd like to remind everyone of BCP 61. It says roughly that > protocols we approve need a mandatory to implement security mechanism. Could the "interoperability reporting" mechanism proposed in: draft-ietf-newtrk-interop-reports-00.txt be extended to include reporting implementation status or review of security mechanisms? The general approach is to take the steps from "Proposed" to "Draft" and break them down and report them individually and explicitly, as a way of breaking the bottleneck. Besides independent, interoperable implementations, and mandatory to implement security mechanisms, and status of normative references, what are the other criteria for advancing a document that could be reported independently? Larry . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 17:05:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gOZ-0007RD-Bd for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 17:05:39 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05692 for ; Fri, 10 Feb 2006 17:03:50 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18Txr3mBJPhgp5irAuK7RwqjEETdO3ESvM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AM3MPU020655; Fri, 10 Feb 2006 14:03:22 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AM3MXg020654; Fri, 10 Feb 2006 14:03:22 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AM3MU4020647 for ; Fri, 10 Feb 2006 14:03:22 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5D93BE006A; Fri, 10 Feb 2006 17:03:16 -0500 (EST) To: RJ Atkinson Cc: saag@mit.edu, newtrk@lists.uoregon.edu, iesg@ietf.org Subject: [newtrk] Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 17:03:16 -0500 In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 08:21:16 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: >> Kerberos: Doable, but we're all fairly busy working on meeting >> new customer needs. We did recently hold a meeting and develop >> feature matrix and roughly what we'd need to remove from the >> spec. We were really hoping that RFC 4120 would not need >> things removed; I think a lot of us lost interest in moving >> Kerberos to draft any time soon when we found out that was not >> the case. RJ> If the issue is that not all features of 4120 are in at least RJ> 2 implementations, there are a couple of approaches. One is RJ> to go find a sponsor to fund someone to add the missing RJ> feature(s) to either MIT Kerberos or Heimdal. The other is to RJ> do what OSPF did with M-OSPF, move the not yet widely RJ> implemented (but perceived useful) items into a separate RJ> document so the main spec can advance more quickly. I think there are one or two things we found that we need a second implementation for. That is relatively easy. We found several items that we'd left in from 1510 because they were harmless. However they are things like X.500 realm names that no one plans to implement and that we don't have interop tests for. They're not actually useful to anyone so removing them is far better than implementing. The challenge is to produce a spec revision that is sufficiently focused. I have lowe confidence that would happen. Remember we're talking about the same people (and I'm as guilty as anyone else in the Kerberos group) who took 11 years to bring pk-init to the IESG. --Sam . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 17:08:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gRT-0000PN-4V for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 17:08:39 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06062 for ; Fri, 10 Feb 2006 17:06:54 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18zbyoyAOpFu0xwY6r5g2JslmglaGz+aPg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ALvrNL020525; Fri, 10 Feb 2006 13:57:53 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1ALvrD4020524; Fri, 10 Feb 2006 13:57:53 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ALvqBO020519 for ; Fri, 10 Feb 2006 13:57:52 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0058CE006A; Fri, 10 Feb 2006 16:57:43 -0500 (EST) To: RJ Atkinson Cc: Peter Gutmann , iesg@ietf.org, newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 16:57:43 -0500 In-Reply-To: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 09:08:26 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> ESP/AH do not depend on PKIX, and they ought not normatively RJ> depend on IKE (or any other automatic key management method), RJ> so ESP/AH should be able to move forward without PKIX. RJ> Similarly, applications that use ESP/AH, should be able to RJ> move forward when ESP/AH move forward, regardless of IKE (or RJ> PKIX). However BCP 107 argues that there should be few applications for which ESP/AH is appropriate without automated key management. I also suspect that ESP/AH depend on the architecture document. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 17:30:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gmR-0001nZ-8C for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 17:30:19 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07365 for ; Fri, 10 Feb 2006 17:28:34 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/EUEinjN+Ztzfi+VJTfy458uI4E8GAyKQ@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AMS7Wf021364; Fri, 10 Feb 2006 14:28:07 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AMS754021363; Fri, 10 Feb 2006 14:28:07 -0800 Received: from smtp.uoregon.edu (mserv4 [128.223.142.54]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AMS7YI021358 for ; Fri, 10 Feb 2006 14:28:07 -0800 Received: from uoregon.edu (geoduck [128.223.142.113]) by smtp.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AMS7Qa032373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Feb 2006 14:28:07 -0800 Received: from localhost (llynch@localhost) by uoregon.edu (8.13.1/8.13.1/Submit) with ESMTP id k1AMS7TM025216 for ; Fri, 10 Feb 2006 14:28:07 -0800 X-Authentication-Warning: geoduck.uoregon.edu: llynch owned process doing -bs Date: Fri, 10 Feb 2006 14:28:07 -0800 (PST) From: "Lucy E. Lynch" X-X-Sender: llynch@geoduck.uoregon.edu To: newtrk@lists.uoregon.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mserv4 X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk appreoved:mabete Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AJVeHK016782 for ; Fri, 10 Feb 2006 11:31:42 -0800 Received: from sandelman.ottawa.on.ca (postfix@res153.cooperix.net [192.139.46.153]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1AJVHJ22783 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 10 Feb 2006 14:31:19 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 11EE33ADA1; Fri, 10 Feb 2006 08:55:36 -0500 (EST) To: Harald Tveit Alvestrand cc: Sam Hartman , newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Harald Tveit Alvestrand of "Fri, 10 Feb 2006 10:02:54 +0100." <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 10 Feb 2006 08:55:36 -0500 Message-ID: <17947.1139579736@sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Harald" == Harald Tveit Alvestrand writes: >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? I think, because there simply isn't the patience left to do things. Harald> I consider the third option - having Draft with Harald> downreference to Proposed - to be a Bad Idea. If we have to Harald> do that, I'd rather abandon Draft. That's quite an indictment of our current three step system. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+ybUYCLcPvd0N1lAQLbOAf9F1QBUK75+tlBGmzJarbzi1t3LyuUaDaS lnQ8OdqSBHJT03tMlepvlKLU/q1Hk5fAhTDWAvCYoZB3kBgYa0/bdNJEfPq8EhmO ywCsHFzbAdu+R5VhjSzyXVVDxuh1+84tXeRph2zVT4tT9W31iyUHxVtJSlXOdwur LH7ZbhLHLIehKM8CgMyNtvaryOR4QKXORLjs2lppruRUnP+tKNLZkupLqsyJv900 T5zpOk+xaN27XmZHwhErSq0NwXJ6U108QDo7AZiZ49ppgIVQEvdcH7eyv5SRp1iH ctisAOGBwEaRYqF+kr4RGAbTl++MsjXT6nsRhg/C2V2bPy0nQ80yBA== =qcXa -----END PGP SIGNATURE----- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 17:36:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gsd-0004Qx-6q for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 17:36:43 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07763 for ; Fri, 10 Feb 2006 17:34:50 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19EM++FM0fYXHe9bKDfxdEaP7cTdQyBbm4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1AMVu37021432; Fri, 10 Feb 2006 14:31:56 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1AMVuhn021431; Fri, 10 Feb 2006 14:31:56 -0800 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by mailapps.uoregon.edu (8.13.5/8.13.5) with SMTP id k1AMSISa021370 for ; Fri, 10 Feb 2006 14:28:18 -0800 Received: (qmail 18298 invoked by uid 0); 10 Feb 2006 22:28:10 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.48) by woodstock.binhost.com with SMTP; 10 Feb 2006 22:28:10 -0000 Message-Id: <7.0.0.16.2.20060210172750.04913de0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 10 Feb 2006 17:28:12 -0500 To: Sam Hartman , Harald Tveit Alvestrand From: Russ Housley Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: saag@mit.edu, newtrk@lists.uoregon.edu, iesg@ietf.org In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk CMS depends on PKIX, so it cannot advance until PKIX does. Russ At 07:34 AM 2/10/2006, Sam Hartman wrote: >CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >was in the best shape. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 18:40:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hsG-000304-5e for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:40:24 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14259 for ; Fri, 10 Feb 2006 18:38:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18pllO/MFJFt2Auua88QrgyFrkwi8zP/m4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ANbRut023201; Fri, 10 Feb 2006 15:37:27 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1ANbRta023200; Fri, 10 Feb 2006 15:37:27 -0800 Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ANbPxD023195 for ; Fri, 10 Feb 2006 15:37:26 -0800 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210233723.FCSD4894.eastrmmtao01.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 18:37:23 -0500 In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, saag@MIT.EDU Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 18:37:18 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 16:57, Sam Hartman wrote: >>>>>> "RJ" == RJ Atkinson writes: > > RJ> ESP/AH do not depend on PKIX, and they ought not normatively > RJ> depend on IKE (or any other automatic key management method), > RJ> so ESP/AH should be able to move forward without PKIX. > RJ> Similarly, applications that use ESP/AH, should be able to > RJ> move forward when ESP/AH move forward, regardless of IKE (or > RJ> PKIX). > > However BCP 107 argues that there should be few applications for which > ESP/AH is appropriate without automated key management. > > I also suspect that ESP/AH depend on the architecture document. I am sympathetic to the notion that no cryptographic system is easy to use without automatic key management. That said, insisting that a mechanism can only progress jointly with its (deliberately architecturally decoupled) key management method mostly seems to increase our process gridlock in a way that seems needless. Given the note at the start of today which started this thread, it seems wisest to keep ESP/AH (and the applications that depend on them -- and probably the IPsec Arch document) de-coupled from ISAKMP/IKE for advancement purposes. There is a clear trade-off between being practical about solving current issues versus being dogmatic about the ideal policy one might prefer in an ideal world. That trade-off is something that the powers that be need to sort out among themselves. I think the tools are already in place so that ESP/AH, IPsec Arch, and their dependent apps could all move rapidly to Draft Standard, without waiting for IKEv2 to get sorted out -- if the powers that be wanted to make that choice. For openers, people continue to use IKEv1 even as IKEv2 is being sorted out. IKEv1 is very widely deployed and used these days. ESP/AH can work with IKEv1 to have automatic key management -- until IKEv2 gets sorted out or KINK gets sorted out or some other better solution appears on the scene. Cheers, Ran . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 18:56:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7i7W-00030F-5g for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:56:10 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15690 for ; Fri, 10 Feb 2006 18:54:25 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/kS5rK0gdzljzYAI2695RQiJE3ykhUyUo@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ANpJoY023486; Fri, 10 Feb 2006 15:51:19 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1ANpJLP023485; Fri, 10 Feb 2006 15:51:19 -0800 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1ANpHci023480 for ; Fri, 10 Feb 2006 15:51:17 -0800 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k1ANp5aD024060 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Feb 2006 15:51:06 -0800 In-Reply-To: <7F378285C91B986C0B7EEA02@p3.JCK.COM> References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58060F70-FBF3-4251-AB78-0E23ED4315AF@mail-abuse.org> Cc: NEWTRK Mailing List Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [newtrk] Re: BCP 61, advancing to draft Date: Fri, 10 Feb 2006 15:51:09 -0800 To: John C Klensin X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 10, 2006, at 8:38 AM, John C Klensin wrote: > > p.s. FWIW, part of the original motivation for ISDs was to provide > a framework for developing and implementing this sort of "document > it and move on" approach. That, and other things, got lost in > arguments about how much text belonged where, how much work the > IESG wanted to do, etc. I lay good odds that if the security area > wants to block anything from moving to Draft unless all of the > relevant security protocols ducks have been lined up and marched to > Draft under the current rules, the discussion of that will waste > significantly more time. Agreed. I would not mind creating another version of the SRD overlay approach, along with support scripts. If there is a desire to include notations and other items, that should not be a problem implement. Linking this with some type of database, (perhaps a moderated wiki) may provide timely information for the participants tracking issues currently in flux, and perhaps offer a repository for warnings and cautions. Any major effort to revamp many documents will make referencing documents even more difficult, where these types of tools and overlays could provide some needed stability. -Doug . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 20:21:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7jSV-0006RZ-1h for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 20:21:55 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27001 for ; Fri, 10 Feb 2006 20:20:11 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/dR053TDxG7Ibb+x8V35w1Newo0imNR5c@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1B1IrG7025536; Fri, 10 Feb 2006 17:18:53 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1B1IrFm025535; Fri, 10 Feb 2006 17:18:53 -0800 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1B1IqGF025518 for ; Fri, 10 Feb 2006 17:18:52 -0800 Received: from sandelman.ottawa.on.ca (postfix@wlan225.sandelman.ca [205.150.200.225]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1B1I6J27959 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 10 Feb 2006 20:18:14 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C8E373AD9C; Fri, 10 Feb 2006 20:18:04 -0500 (EST) To: Paul Hoffman cc: Harald Tveit Alvestrand , Sam Hartman , newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org Subject: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Paul Hoffman of "Fri, 10 Feb 2006 06:52:33 PST." References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 10 Feb 2006 20:18:04 -0500 Message-ID: <3028.1139620684@sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Speaking from an IPsec point of view: - the majority of IPsec vendors are selling VPN. - few of us even have host implementations on which another protocol could really use our security service. (This in itself is very sad) - so, there is almost no market push for IPsec vendors to take a further interest in the process. None of *our* customers would care. Now, the vendors who do have host integrated implementations: KAME/BSD, Solaris, Linux and Microsoft, might be persuaded to care, but in most cases the upper layer protocols that want IPsec are still not part of our portfolio. Which documents are waiting on IPsec to go to PS? For which vendors is this a *market* problem for them? - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+07S4CLcPvd0N1lAQKGbAf/aY4X0TrYLgkM7qB5Bwe86JOvXAAVMCOb mqCNpVSPALHjF5vESshrFyad++CYraEe998ya5SwmRq0n2RDzOFb3pC+Vkj03tF2 UibgsZxGR7dmL8jw1eGMJKmIURdEUOhSoMvuegjm4xdLTRgRaJOguOUvFURNejkj 1q3ajzJFpfuFZpfR4bvubHyFOyYJ3ASfmQIstiIdOGbpzb+3VhZXLKAL+XbShptC Zs4dg3ydMHop8gLykJ0+RkWVxUaHrvYhs4mp/wtqGBdGe0CmXr6aaR2ifLHO34oM JIrbemREYbBU0JPgkY+iDWtZh5fNmePp6OieSLEr6OgKtoqvN5S0HA== =9kAw -----END PGP SIGNATURE----- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 10 21:53:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ksm-0003Y4-38 for newtrk-archive@megatron.ietf.org; Fri, 10 Feb 2006 21:53:10 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01795 for ; Fri, 10 Feb 2006 21:51:16 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/gzZ+gWI+4QNJjWVP0fROPc3+RTo9maNk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1B2lVLq026611; Fri, 10 Feb 2006 18:47:31 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1B2lVps026610; Fri, 10 Feb 2006 18:47:31 -0800 Received: from carter-zimmerman.mit.edu (STRATTON-THREE-EIGHTY-ONE.MIT.EDU [18.187.6.126]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1B2lU8p026605 for ; Fri, 10 Feb 2006 18:47:30 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 94731E0053; Fri, 10 Feb 2006 21:47:24 -0500 (EST) To: RJ Atkinson Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 21:47:24 -0500 In-Reply-To: (RJ Atkinson's message of "Fri, 10 Feb 2006 18:37:18 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> Given the note at the start of today which started this RJ> thread, it seems wisest to keep ESP/AH (and the applications RJ> that depend on them -- and probably the IPsec Arch document) RJ> de-coupled from ISAKMP/IKE for advancement purposes. RJ> There is a clear trade-off between being practical about RJ> solving current issues versus being dogmatic about the ideal RJ> policy one might prefer in an ideal world. That trade-off is RJ> something that the powers that be need to sort out among RJ> themselves. I think the community (and the leadership) have spoken on this issue. I think we said that we all believe that automated key management is really important from a technical standpoint. I'd much rather have proposed standards that have automated key management than draft standards that assume people will use manual keying. --Sam . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 01:17:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7o4H-0001zu-VI for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 01:17:17 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12605 for ; Sat, 11 Feb 2006 01:15:20 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18CwRjcbvtlnSsar5OThV89yHJoy2gvdLM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1B6EfZ6028969; Fri, 10 Feb 2006 22:14:41 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1B6EfsB028968; Fri, 10 Feb 2006 22:14:41 -0800 Received: from mail126.messagelabs.com (mail126.messagelabs.com [216.82.250.99]) by mailapps.uoregon.edu (8.13.5/8.13.5) with SMTP id k1B6EfSM028963 for ; Fri, 10 Feb 2006 22:14:41 -0800 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-126.messagelabs.com!1139638475!9562577!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 978 invoked from network); 11 Feb 2006 06:14:35 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-13.tower-126.messagelabs.com with SMTP; 11 Feb 2006 06:14:35 -0000 Received: from [135.70.102.74] (unknown[135.70.102.74](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060211061434gw1001004je> (Authid: tony); Sat, 11 Feb 2006 06:14:34 +0000 Message-ID: <43ED80C7.9010608@att.com> Date: Sat, 11 Feb 2006 01:14:31 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is it time to move beyond volunteers? Perhaps we need to ask some organization (ISOC? IGB? ????) if they would be willing to support an effort to do the interop testing? Tony Hansen tony@att.com Paul Hoffman wrote: > One big issue we have with security protocols moving to draft is that > there is very little volunteer interest in testing SHOULD/MUST > interop beyond the basics (if even that). Our protocols have a lot of > SHOULDs that have nothing to do with interop and are very difficult > to test. But, even without those, the security area has been much > less active at voluntary interop testing than other areas, which > makes "going to Draft" not appealing. We are generally happy to cycle > at Proposed. Sam's message points out a significant ramification of > that attitude, although I don't have a proposed solution to the > problem. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 09:06:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7vO9-0006r9-EN for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 09:06:13 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06999 for ; Sat, 11 Feb 2006 09:04:29 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/fxBDgDILOjYaIySNKurjygtxX+y6e/+8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BE3vvr004250; Sat, 11 Feb 2006 06:03:57 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BE3v4V004249; Sat, 11 Feb 2006 06:03:57 -0800 Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BE3ujx004242 for ; Sat, 11 Feb 2006 06:03:57 -0800 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060211140353.LASO4894.eastrmmtao01.cox.net@[10.30.20.240]>; Sat, 11 Feb 2006 09:03:53 -0500 In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, saag@MIT.EDU Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Sat, 11 Feb 2006 09:03:49 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 21:47, Sam Hartman wrote: > I think the community (and the leadership) have spoken on this issue. > I think we said that we all believe that automated key management is > really important from a technical standpoint. > > I'd much rather have proposed standards that have automated key > management than draft standards that assume people will use manual > keying. You can have draft standards with automated key management. It only requires advancing IKEv1 separately from (in parallel with) IKEv2. If you'd like to do that but think the current rules don't allow, then lets have a discussion about fixing the rules. IKEv1 isn't going away anytime soon from the deployed world, simply because it will take a while (probably years, if history holds true) before there are multiple IKEv2 implementations that can talk with each other, regardless of what the IETF does. It took IKEv1 some number of years to reach that state, despite active interoperability testing throughout that period. So such a modest step as advancing the 2 versions of IKE in parallel is not harming deployed security at all. It is a choice that the IESG gets to make. The bottom line is in your last paragraph, which basically says that you are comfortable having a lot of application protocols stuck at PS for a while, possibly years. If that is true, why should ordinary IETF participants feel much incentive to progress anything beyond PS ? I'm not upset with anyone or any group, but I am greatly confused by the thread of the past day or so. Cheers, Ran PS: Not speaking for my employer, but one of the observations from when I've occasionally been an end-user (ISP or other end user) is that the market need is for a stable openly published specification and for interoperability. The market does not care a great deal whether something is PS, DS, FS, or Informational. PPS: What Michael Richardson says, echos my PS just above, and sadly enough, has been true of the IPsec WG for almost 10 years now. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 10:25:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7wcd-0001n2-My for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 10:25:15 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10440 for ; Sat, 11 Feb 2006 10:23:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1874REK+/Ha2nh4pEmSJCwJL5iOVft0Ptg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFFrKb005542; Sat, 11 Feb 2006 07:15:53 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BFFr7w005541; Sat, 11 Feb 2006 07:15:53 -0800 Received: from above.proper.com (above.proper.com [208.184.76.39]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFFqve005536 for ; Sat, 11 Feb 2006 07:15:52 -0800 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1BFFhkE047289; Sat, 11 Feb 2006 07:15:44 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Date: Sat, 11 Feb 2006 07:15:21 -0800 To: RJ Atkinson , Sam Hartman From: Paul Hoffman Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk At 9:03 AM -0500 2/11/06, RJ Atkinson wrote: >You can have draft standards with automated key management. >It only requires advancing IKEv1 separately from (in parallel with) >IKEv2. That "only" assumes that there is interest in doing the work of testing every SHOULD and MUST; so far, there has not been. The "only" also assumes that there are multiple interoperable implementations of every SHOULD and MUST, which there is not. >It is a choice that the IESG gets to make. No, it is a choice that the IPsec community gets to make. In the over seven years since IKEv1 has been around, there has not been interest in testing for the purpose of advancing the category of the protocol. >The bottom line is in your last paragraph, which basically says >that you are comfortable having a lot of application protocols >stuck at PS for a while, possibly years. I read it differently: the IETF is willing to accept that some protocols will never advance in status because they rely on other protocols which will never advance in status. I don't see a lot of "comfort" there. --Paul Hoffman, Director --VPN Consortium . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 10:47:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7wyE-0001Dg-A6 for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 10:47:34 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11558 for ; Sat, 11 Feb 2006 10:45:49 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19IDg71MEQvRyfTVCFeq/TaG87yz80oDsY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFjkLV005823; Sat, 11 Feb 2006 07:45:46 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BFjkiW005822; Sat, 11 Feb 2006 07:45:46 -0800 Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFjjDZ005816 for ; Sat, 11 Feb 2006 07:45:46 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1BFjdVV213378 for ; Sat, 11 Feb 2006 15:45:39 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1BFjfqa212926 for ; Sat, 11 Feb 2006 16:45:41 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1BFjdiu003057 for ; Sat, 11 Feb 2006 16:45:39 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1BFjcB5003052; Sat, 11 Feb 2006 16:45:38 +0100 Received: from zurich.ibm.com (sig-9-146-217-248.de.ibm.com [9.146.217.248]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA41594; Sat, 11 Feb 2006 16:45:37 +0100 Message-ID: <43ED9C55.6010108@zurich.ibm.com> Date: Sat, 11 Feb 2006 09:12:05 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John C Klensin CC: Sam Hartman , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Re: BCP 61, advancing to draft References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> In-Reply-To: <7F378285C91B986C0B7EEA02@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > > --On Friday, 10 February, 2006 10:41 +0100 Brian E Carpenter > wrote: > > >>(cc's stripped, AD hat off). >> >> > Does anyone want to work on a better answer to this? >> >>Yes. draft-carpenter-newtrk-twostep or >>draft-loughney-newtrk-one-size-fits-all >> >> Brian > > > Or > draft-ietf-newtrk-repurposing-isd > > With explicit qualifying language about these cases (not just a > downref, about which I agree with Harald). I don't see > "twostep" as being helpful to this problem, since there would > still be a downref problem. John, my twostep draft explicitly allows downrefs in all cases. That can be debated of course, but that was my proposal. It also is completely compatible with an ISD like approach, but doesn't require it to solve the downref problem. Brian > > or, if we can't solve this problem (for some plausible value of > "solve" without abandoning a multi-stage process, the > hypothetical > > draft-(hypothetical)-merger-ISO/IEC-JTC1/SCnn > > More seriously, I continue to favor a rule that says that, if > someone has achieved wide deployment and interoperability > demonstrated in production implementations, we should write up > any concerns we have about the thing and then move the whole > business, list of concerns and all, directly to full standard. > It seems to me that we need to remember that, whether we have > one standards maturity level, or two or three or four, those > levels are tied to maturity of definition and interoperable > implementations, not to whether we recommend the thing. We > still have "required/ recommended/ not recommended" in our > traditions somewhere, in spite of never assigning them any more. > One inference to be drawn from Sam's note is that we are > beginning to resemble a slapstick act: first we find a large > block and call it a "rule", then we put it in front of > ourselves, and then we trip over it and fall down. > > Let's take TLS as an example. No one serious can make a case > that it is not widely deployed, or that there are not multiple > implementations, or that those implementations are not > interoperable. So it depends on some externalities that are not > resolved in a way that we'd consider optimal (such as a good PKI > structure) and we don't have completely satisfactory ways of > dealing with some issues. So... document those observations as > risks, warn people that they should be aware of problems that > might occur in the future and that they should watch for an > improved "version N+1". Then get it out there and put this to > rest. > > The reality is that, if anyone really waited for things to meet > the IETF's current rules for full standards, we'd be running > telnet, FTP, email, and little else on the network -- at least > until someone deprecated them for not meeting those standards. > > john > > p.s. FWIW, part of the original motivation for ISDs was to > provide a framework for developing and implementing this sort of > "document it and move on" approach. That, and other things, got > lost in arguments about how much text belonged where, how much > work the IESG wanted to do, etc. I lay good odds that if the > security area wants to block anything from moving to Draft > unless all of the relevant security protocols ducks have been > lined up and marched to Draft under the current rules, the > discussion of that will waste significantly more time. > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 10:49:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7wzl-0001WP-19 for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 10:49:09 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11647 for ; Sat, 11 Feb 2006 10:47:24 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19d6KXEtkzhMpiEKRIr2dLwcRsPHIOtOMM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFiC2j005791; Sat, 11 Feb 2006 07:44:12 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BFiCCN005790; Sat, 11 Feb 2006 07:44:12 -0800 Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFiC27005785 for ; Sat, 11 Feb 2006 07:44:12 -0800 Received: from azsmsxvs041.ch.intel.com (azsmsxvs041.ch.intel.com [143.182.252.55]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.10/d: small-solo.mc,v 1.2 2004/09/17 18:05:04 root Exp $) with SMTP id k1BFjKdv019113; Sat, 11 Feb 2006 15:45:24 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs041.ch.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006021108433117611 ; Sat, 11 Feb 2006 08:43:32 -0700 Received: from azsmsx311.amr.corp.intel.com ([10.2.161.35]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Feb 2006 08:42:57 -0700 Received: from mail pickup service by azsmsx311.amr.corp.intel.com with Microsoft SMTPSVC; Sat, 11 Feb 2006 08:42:56 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by azsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Feb 2006 07:29:46 -0700 Received: from orsmsx311.amr.corp.intel.com ([192.168.65.40]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Feb 2006 06:30:05 -0800 Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Feb 2006 06:29:30 -0800 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Feb 2006 06:07:55 -0800 Received: from orsmga101.jf.intel.com ([10.7.208.22]) by orsmga001.jf.intel.com with ESMTP; 11 Feb 2006 06:08:54 -0800 X-IronPort-AV: i="4.02,104,1139212800"; d="scan'208"; a="8017172:sNHT87761793" Received: from jis.mit.edu ([18.7.21.84]) by orsmga101.jf.intel.com with ESMTP; 11 Feb 2006 06:05:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,104,1139212800"; d="scan'208"; a="18119075:sNHT17833536" Received: from jis.mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id k1BE49sM018955; Sat, 11 Feb 2006 09:04:10 -0500 (EST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id k1BE41sL018951 for ; Sat, 11 Feb 2006 09:04:06 -0500 (EST) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) k1BE3pON027132; Sat, 11 Feb 2006 09:03:52 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060211140353.LASO4894.eastrmmtao01.cox.net@[10.30.20.240]>; Sat, 11 Feb 2006 09:03:53 -0500 In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Sat, 11 Feb 2006 09:03:49 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.746.2) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.165761 Spam-Alum-Time: 0.608512 cc: iesg@ietf.org cc: newtrk@lists.uoregon.edu cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-OriginalArrivalTime: 11 Feb 2006 14:07:55.0749 (UTC) FILETIME=[8E283950:01C62F14] X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2006, at 21:47, Sam Hartman wrote: > I think the community (and the leadership) have spoken on this issue. > I think we said that we all believe that automated key management is > really important from a technical standpoint. > > I'd much rather have proposed standards that have automated key > management than draft standards that assume people will use manual > keying. You can have draft standards with automated key management. It only requires advancing IKEv1 separately from (in parallel with) IKEv2. If you'd like to do that but think the current rules don't allow, then lets have a discussion about fixing the rules. IKEv1 isn't going away anytime soon from the deployed world, simply because it will take a while (probably years, if history holds true) before there are multiple IKEv2 implementations that can talk with each other, regardless of what the IETF does. It took IKEv1 some number of years to reach that state, despite active interoperability testing throughout that period. So such a modest step as advancing the 2 versions of IKE in parallel is not harming deployed security at all. It is a choice that the IESG gets to make. The bottom line is in your last paragraph, which basically says that you are comfortable having a lot of application protocols stuck at PS for a while, possibly years. If that is true, why should ordinary IETF participants feel much incentive to progress anything beyond PS ? I'm not upset with anyone or any group, but I am greatly confused by the thread of the past day or so. Cheers, Ran PS: Not speaking for my employer, but one of the observations from when I've occasionally been an end-user (ISP or other end user) is that the market need is for a stable openly published specification and for interoperability. The market does not care a great deal whether something is PS, DS, FS, or Informational. PPS: What Michael Richardson says, echos my PS just above, and sadly enough, has been true of the IPsec WG for almost 10 years now. _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 10:50:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7x1S-0001mu-BX for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 10:50:54 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11794 for ; Sat, 11 Feb 2006 10:49:09 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/D33iZ2fLnH0Tcb0zLHMyfDzeCR87kruo@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFjmDK005834; Sat, 11 Feb 2006 07:45:48 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BFjmwu005833; Sat, 11 Feb 2006 07:45:48 -0800 Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [195.212.29.135]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BFjluL005817 for ; Sat, 11 Feb 2006 07:45:47 -0800 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k1BFjfm9196808 for ; Sat, 11 Feb 2006 15:45:41 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1BFjgSt219164 for ; Sat, 11 Feb 2006 15:45:42 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k1BFje4O007354 for ; Sat, 11 Feb 2006 15:45:40 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k1BFjerw007351; Sat, 11 Feb 2006 15:45:40 GMT Received: from zurich.ibm.com (sig-9-146-217-248.de.ibm.com [9.146.217.248]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA61066; Sat, 11 Feb 2006 16:45:39 +0100 Message-ID: <43ED9EB8.8000006@zurich.ibm.com> Date: Sat, 11 Feb 2006 09:22:16 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Spencer Dawkins CC: newtrk@lists.uoregon.edu, "RJ Atkinson" Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> In-Reply-To: <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments in line... Spencer Dawkins wrote: > Trimming down to Newtrk plus Ran (I don't know if Ran is on Newtrk, but > all of the other process-ish discussants are - and Ran, please take this > as a compliment, because it means you may have been doing real work :-)... > > >> 1) Proposed Standard >> - Rules exactly as they are to progress to Proposed Standard >> - No Changes >> 2) Delete the "Draft Standard" state, but keep the "multiple >> interoperable >> implementations" rule and apply that rule to "Full Standard". This is pretty much draft-carpenter-newtrk-twostep so far > > > There have been several two-stage suggestions previously, and I liked > most of them, so I like Ran's particular variant, certainly as a > starting point. > >> 3) Require that most Proposed Standards (i.e. those that are not blocked >> by the failure of some other standard to advance) move to Full >> Standard within 2 years (edit time to your taste) of publication >> as a Proposed Standard or 2 years of all normative references >> moving to Full Standard, whichever comes later. Anything that >> does not meet that requirement automatically gets reclassified >> as HISTORIC status unless the IESG grants an exception at the >> 2 year timeout. IESG exceptions are themselves limited to 2 years. >> Any IESG exception requires the IESG to publicly say why the >> exception was granted in the particular case. > > > I have two comments here. One is that any time we have made noises like > "gee, how 'bout we actually do what RFC 2026, and RFC 1620 before that, > and RFC 1310 before that, say we're going to do, and bail all the old > Proposed Standards to Historic if there's no energy to advance them", > total panic has broken out. > > Let me be very clear. We have never had time to do what our standards > process says we do, except in exceptional cases. Extrapolating from > roughly March 1992, I'm guessing that we never will. Proposals that > assume a 90-degree turn need to explain the physics that result in that > turn. > > I happen to like where Ran is headed, because I think (sighting along > the top of his head forward), we would be headed to a place were we > don't have as many active standards-track documents - but the ones we > have, are the ones that we care about. For me personally, the DeCruft > work was depressing because the criteria seemed to be, "well, if this > RFC was FTPed over a satellite link, we have to make sure that 'no one > on another planet might have been eavesdropping and might now be > thinking about planning to use it' before we can move it to Historic". > "No energy" means "no standard", given a certain amount of time. Doesn't > make the documents vaportize, just tells the rest of the world that this > once-Proposed Standard is getting no attention from anyone, so should > realistically be "use at own risk". I disagree. As we saw during the multiple last calls and reviews of the decruft draft, there are lots of old PS documents that are claimed to be in active use and I'm willing to bet we missed one or two. Why cause hassle and annoy people by blindly demoting them? My twostep draft explicitly removes the notion that staying for ever in PS is a bug. I still believe that by reducing the number of stages from 3 to 2 we would make it significantly more attractive to people to make the effort to produce implementation reports, because by doing so they would achieve "final status". But I don't think automatic demotion of standards would cause anything but annoyance. Incidentally, I wrote the twostep draft before I became the responsible AD. Is there anybody out there who would like to take over as author? xml2rfc source is available. Brian > > Just FWIW, I'm not sure that the reclassification needs to be an IESG > responsibility - we've had 13(ish) ADs put these protocols on the > standards track, knowing full well that many of these protocols will be > implemented and widely deployed; does it take 13 ADs to say, "well, > maybe this document should advance"? Since the alternative seems to be > encouraging people to pay no attention at all to standards maturity > levels, perhaps "seems mostly harmless" would be an acceptable reason > for an exception. But that's a side issue. > > Second - and this is a way-detailed comment on Ran's proposal - I > happened to notice > http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from another > standards organization; their algorithm is "gotta look at every standard > every five years and pick of (1) reaffirm, (2) revise, or (3) withdraw". > We've sorta/kinda done the pass looking at the Proposed Standards that > we wanted to withdraw. If we made another pass saying, "these are the > ones we want to reaffirm; we think they are OK for advancement", we > might be pretty close to what (I understood) Ran was proposing. And if > the first-pass number was three years, and the extension was two years, > that would give us the same horizon IEEE 802 uses (which doesn't make it > right, but doesn't make it wrong, either). > > Thanks, > > Spencer > > . > newtrk resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 11:31:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7xf3-0000zM-Ta for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 11:31:50 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15146 for ; Sat, 11 Feb 2006 11:30:05 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19UDFM2BqCVNd3iPTmB97X01inHAc/1+h0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BGQa5Q006672; Sat, 11 Feb 2006 08:26:36 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BGQaeE006671; Sat, 11 Feb 2006 08:26:36 -0800 Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BGQahN006666 for ; Sat, 11 Feb 2006 08:26:36 -0800 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc11) with SMTP id <20060211162630m110017om7e>; Sat, 11 Feb 2006 16:26:30 +0000 Message-ID: <0ab501c62f27$b1dd05c0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: Cc: "RJ Atkinson" References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> <010301c62e60$42e5eaa0$0500a8c0@china.huawei.com> <43ED9EB8.8000006@zurich.ibm.com> Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft Date: Sat, 11 Feb 2006 10:24:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have an inline comment further down, but just as prelude ... am I the only person who thinks that we are wedged in the least reasonable standards track structure, and that almost any change we make would be more reasonable (especially if we actually started to do what the process says we do)? I happened to like the twostep draft, because I thought it would be an improvement. I also liked a lot of other drafts that have been banging around in Newtrk, because I thought they would also be improvements. From: "Brian E Carpenter" > Comments in line... > > Spencer Dawkins wrote: >> I happen to like where Ran is headed, because I think (sighting along the >> top of his head forward), we would be headed to a place were we don't >> have as many active standards-track documents - but the ones we have, are >> the ones that we care about. For me personally, the DeCruft work was >> depressing because the criteria seemed to be, "well, if this RFC was >> FTPed over a satellite link, we have to make sure that 'no one on another >> planet might have been eavesdropping and might now be thinking about >> planning to use it' before we can move it to Historic". "No energy" means >> "no standard", given a certain amount of time. Doesn't make the documents >> vaportize, just tells the rest of the world that this once-Proposed >> Standard is getting no attention from anyone, so should realistically be >> "use at own risk". > > I disagree. As we saw during the multiple last calls and reviews of > the decruft draft, there are lots of old PS documents that are claimed > to be in active use and I'm willing to bet we missed one or two. Why > cause hassle and annoy people by blindly demoting them? I may have misunderstood, but I thought one of the challenges of decruft was communities who did their work in the IETF, deployed a protocol, and went home victorious - ten or fifteen years ago, leaving a standards-track RFC hanging at PS. To use one example (cited by Pekka), do we think that anyone in the X.25 community would be hassled or annoyed when RFC 1381 and RFC 1382 move to historic? People may be using X.25 MIBs in operational networks every day, but is any purpose served when we continue to carry these specifications in the same category as RFC 3261 (SIP)? If the RFC Editor was looking to our standards classifications as a clue about removing RFCs from the RFC repository, so Historic specifications might actually evaporate, I could better understand our hesitation, but since we have almost every RFC ever issued still available online, plus the Internet Engineering Note series, I just don't "get it". Sorry. > My twostep draft explicitly removes the notion that staying for ever > in PS is a bug. I still believe that by reducing the number of stages > from 3 to 2 we would make it significantly more attractive to people to > make the effort to produce implementation reports, because by > doing so they would achieve "final status". But I don't think automatic > demotion of standards would cause anything but annoyance. I don't think that hanging in PS forever has to be a bad thing, but it's a bad thing now, because it's documented as a bad thing in 2026. But as to whether it's a good thing ... OK, let's hypothetically assume that someone becomes interested in working on protocol specifications now. I believe that this hypothetical newbie has a pretty steep learning curve ahead, and the forest of specifications on the standards track won't help with that learning curve. So I'm wondering why annoying people who no longer participate in IETF matters more than annoying people who do? Thanks, Spencer . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 12:32:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ybh-0004rX-9d for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 12:32:27 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18705 for ; Sat, 11 Feb 2006 12:30:40 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+8IzZmPAi8JJZrlqB5G8lph/CbvwgCF5o@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BHTVN7007666; Sat, 11 Feb 2006 09:29:31 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BHTVpU007665; Sat, 11 Feb 2006 09:29:31 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BHTP44007660 for ; Sat, 11 Feb 2006 09:29:25 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F7yYj-000JRN-DL; Sat, 11 Feb 2006 12:29:21 -0500 Date: Sat, 11 Feb 2006 12:29:20 -0500 From: John C Klensin To: Brian E Carpenter cc: Sam Hartman , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Re: BCP 61, advancing to draft Message-ID: <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> In-Reply-To: <43ED9C55.6010108@zurich.ibm.com> References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> <43ED9C55.6010108@zurich.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, 11 February, 2006 09:12 +0100 Brian E Carpenter wrote: >> With explicit qualifying language about these cases (not just >> a downref, about which I agree with Harald). I don't see >> "twostep" as being helpful to this problem, since there would >> still be a downref problem. > > John, my twostep draft explicitly allows downrefs in all cases. > That can be debated of course, but that was my proposal. > It also is completely compatible with an ISD like approach, > but doesn't require it to solve the downref problem. Sorry, I obviously wrote too quickly to be clear. I believe that "no downrefs with an exception procedure" (i.e., what we have today plus or minus quibbles) is a necessary element of preserving a multiple-step standards process. Without it, I think things rapidly deteriorate to single-step whether that is the intention or not. I think the model of RFC 3967 is one way out of the trap your draft identifies. I think that there could be several other models, including a requirement to explicitly document what is being done in, e.g., an annotation to the reference that became part of the Last Call review. Some would consider that a streamlining of the 3967 procedure, others as closer to "just do the downref and don't worry about it". But, in any event, what I intended by "... still be a downref problem..." was "we would still need to sort out what to do about those cases". Obviously, if your twostep draft were adopted without alteration or further discussion, that problem would be eliminated but I didn't see that happening and, at the moment, that draft is as dead as the ISD one(s). best, john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 13:37:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7zcS-0000Zw-NO for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 13:37:16 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21860 for ; Sat, 11 Feb 2006 13:35:31 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+EWfXdLsptQ19A4YWrhICnSp7J1WFYmoo@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BIYXXc008775; Sat, 11 Feb 2006 10:34:33 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BIYXuX008774; Sat, 11 Feb 2006 10:34:33 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BIYWsu008769 for ; Sat, 11 Feb 2006 10:34:32 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7524AE0053; Sat, 11 Feb 2006 13:34:21 -0500 (EST) To: Paul Hoffman Cc: RJ Atkinson , iesg@ietf.org, newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> From: Sam Hartman Date: Sat, 11 Feb 2006 13:34:21 -0500 In-Reply-To: (Paul Hoffman's message of "Sat, 11 Feb 2006 07:15:21 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "Paul" == Paul Hoffman writes: Paul> That "only" assumes that there is interest in doing the work Paul> of testing every SHOULD and MUST; so far, there has not Paul> been. The "only" also assumes that there are multiple Paul> interoperable implementations of every SHOULD and MUST, Paul> which there is not. Testing every should and must is not required. You need to test every protocol feature. That is a simpler task. However I suspect there still is not interest in doing that. --Sam . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 13:59:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7zxX-0007T5-PJ for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 13:59:06 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23122 for ; Sat, 11 Feb 2006 13:57:18 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19VG7RWR2Hwl0/6zrHF1pdOug+l+D4BTfA@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BIov6F008941; Sat, 11 Feb 2006 10:50:57 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BIovjb008940; Sat, 11 Feb 2006 10:50:57 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BIougq008935 for ; Sat, 11 Feb 2006 10:50:56 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8FDDCE0053; Sat, 11 Feb 2006 13:50:46 -0500 (EST) To: John C Klensin Cc: Brian E Carpenter , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Re: BCP 61, advancing to draft References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> <43ED9C55.6010108@zurich.ibm.com> <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> From: Sam Hartman Date: Sat, 11 Feb 2006 13:50:46 -0500 In-Reply-To: <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> (John C. Klensin's message of "Sat, 11 Feb 2006 12:29:20 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk John, I will observe that I have found significant value in going back and making the revisions to specifications to address clarity problems based on deployment and to remove unused features. I'we witnessed this with IPsec and participated in many years of it with Kerberos. I'm also involved in the current effort of this form with SASL. I agree that this process is critical to the IETF's success. I cannot say however that I have seen significant value in waiting for references. If a spec is clear enough that you can get multiple interoperable implementations and can document that fact, it seems like you've said something about the normative references. I'm not quite sure what that something is, but I think it is sufficient. In effect, I'm saying that the pragmatic test of "are the downrefs good enough that we can get multiple interoperable implementations without cringing," is a good enough test. For that reason, I believe that there is little value in requiring people to go out of their way for down references. There probably i value in allowing specific objections of the form "that downref isn't of sufficient quality to understand this spec." --Sam If you disagree, I'd ask you to focus in your disagreement on how the down reference rules improve the quality of our specifications in practice. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 15:19:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F81DH-00065y-6V for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 15:19:23 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26829 for ; Sat, 11 Feb 2006 15:17:39 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19N1oMyFlv+iUuKSIq+R0LYBpbBXvnHEgI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BKGNMk010565; Sat, 11 Feb 2006 12:16:23 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BKGNHS010564; Sat, 11 Feb 2006 12:16:23 -0800 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BKGH84010559 for ; Sat, 11 Feb 2006 12:16:17 -0800 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k1BKG3GA014032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 11 Feb 2006 12:16:03 -0800 Subject: Re: [newtrk] Re: BCP 61, advancing to draft From: Douglas Otis To: John C Klensin Cc: Brian E Carpenter , Sam Hartman , newtrk@lists.uoregon.edu In-Reply-To: <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> <43ED9C55.6010108@zurich.ibm.com> <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> Content-Type: text/plain Date: Sat, 11 Feb 2006 12:16:02 -0800 Message-Id: <1139688962.12199.202.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2006-02-11 at 12:29 -0500, John C Klensin wrote: > > Obviously, if your twostep draft were adopted without alteration or > further discussion, that problem would be eliminated but I didn't see > that happening and, at the moment, that draft is as dead as the ISD > one(s). Reference stability is likely of comparable merit to that of references to documents at various levels of classification. The ISD proposal at least attempted to provide stable user-friendly references, and the SRD attempted something very similar, but with less effort. Apparently, still too much or too messy. Would the IESG consider a mechanical updating of documents to replace all RFCXXXX names with a hierarchical {order}.... This may require converting existing RFCs into a form that can generate new outputs as discussed on the IETF mailing list. Naming could be compared to an attempt to compose a set of books where an RFC represent a chapter. Once a family/genus name is created for each RFC, a script could provide the substitution, together with the renamed xml bibliography. Lookups for RFCXXXX could reference to the new name. Depending upon the status of the RFC, it could be organized into different {orders} such as IS/PS. -Doug . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 17:05:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F82rW-0004S4-7D for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 17:05:02 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02235 for ; Sat, 11 Feb 2006 17:03:17 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX187jSuaIpjDvfHaFHmsFlk0wGli4WOlFT4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BM2mLa012908; Sat, 11 Feb 2006 14:02:48 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BM2m8D012907; Sat, 11 Feb 2006 14:02:48 -0800 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BM2m4t012902 for ; Sat, 11 Feb 2006 14:02:48 -0800 Received: from [128.9.176.130] (ras30.isi.edu [128.9.176.130]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1BM1iq06185; Sat, 11 Feb 2006 14:01:44 -0800 (PST) Message-ID: <43EE5EC1.9080007@isi.edu> Date: Sat, 11 Feb 2006 14:01:37 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sam Hartman CC: Paul Hoffman , RJ Atkinson , iesg@ietf.org, newtrk@lists.uoregon.edu, saag@mit.edu Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC9D7DD12C82FD099A3A1735" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC9D7DD12C82FD099A3A1735 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sam Hartman wrote: >>>>>> "Paul" =3D=3D Paul Hoffman writes: >=20 > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. >=20 > Testing every should and must is not required. That seems odd; what is sufficient protocol testing if not to validate the MUST and MUST NOTs? Joe --------------enigCC9D7DD12C82FD099A3A1735 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD7l7BE5f5cImnZrsRAn/OAJ9KCvfMFIC4SVj7PZe7QLSi9TtDlQCgnZmz IqVv1Zf1IoZEYUzXnCwUFlk= =Qa3h -----END PGP SIGNATURE----- --------------enigCC9D7DD12C82FD099A3A1735-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 11 17:34:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F83KF-0005LJ-GB for newtrk-archive@megatron.ietf.org; Sat, 11 Feb 2006 17:34:45 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03715 for ; Sat, 11 Feb 2006 17:32:58 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18jFjOZGm3WJbWr+F4DDdUQhcvUsjiyFYs@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BMTkPZ013344; Sat, 11 Feb 2006 14:29:46 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1BMTkKl013343; Sat, 11 Feb 2006 14:29:46 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1BMTjiw013338 for ; Sat, 11 Feb 2006 14:29:45 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1F83FM-000JpH-Ij; Sat, 11 Feb 2006 17:29:40 -0500 Date: Sat, 11 Feb 2006 17:29:39 -0500 From: John C Klensin To: Sam Hartman cc: Brian E Carpenter , newtrk@lists.uoregon.edu Subject: Re: [newtrk] Re: BCP 61, advancing to draft Message-ID: <0D915418FE142CAD6A1A2AED@p3.JCK.COM> In-Reply-To: References: <43EC5FB0.4040404@zurich.ibm.com> <7F378285C91B986C0B7EEA02@p3.JCK.COM> <43ED9C55.6010108@zurich.ibm.com> <6A9B4AB603B63D333EC0DB47@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, 11 February, 2006 13:50 -0500 Sam Hartman wrote: > John, I will observe that I have found significant value in > going back and making the revisions to specifications to > address clarity problems based on deployment and to remove > unused features. I'we witnessed this with IPsec and > participated in many years of it with Kerberos. I'm also > involved in the current effort of this form with SASL. I > agree that this process is critical to the IETF's success. > > I cannot say however that I have seen significant value in > waiting for references. If a spec is clear enough that you > can get multiple interoperable implementations and can > document that fact, it seems like you've said something about > the normative references. I'm not quite sure what that > something is, but I think it is sufficient. > > In effect, I'm saying that the pragmatic test of "are the > downrefs good enough that we can get multiple interoperable > implementations without cringing," is a good enough test. For > that reason, I believe that there is little value in requiring > people to go out of their way for down references. There > probably i value in allowing specific objections of the form > "that downref isn't of sufficient quality to understand this > spec." I think we agree, or at least nearly so. All I propose is that we make an effort to distinguish between references that are presumed to be of the same quality and maturity as the specification under consideration and those that are not. For that latter, I think that, in the interest of stability and retention of meaning when the referenced documents are updated, we need to make a reasonable effort to document the level of stability. I don't think that documentation process need be extensive. Statements such as "the use of this for option N within this document seems sufficient while that for option M is less certain" or "this document is under review and may be updated, but the reference from this specification applies specifically to the text in section XX; any revisions to that referenced spec do not apply to this standard" or "the referenced specification is under revision, but this specification depends on the interpretation of that reference as documented in the so-far-unapproved revisions" should be sufficient. > --Sam If you disagree, I'd ask you to focus in your > disagreement on how the down reference rules improve the > quality of our specifications in practice. I think the situation is very different from the established and deployed specification you posit above and a relatively newer piece of work. For the former, information about how stable the technology is on which the specification depends may be important, but mostly for distinguishing boundaries and the details of dependencies. For the latter, that same information may be critical in making decisions about what to implement and when. Watch for a draft. john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sun Feb 12 10:53:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8JX7-0000Wl-6A for newtrk-archive@megatron.ietf.org; Sun, 12 Feb 2006 10:53:05 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25434 for ; Sun, 12 Feb 2006 10:51:19 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19uUTZj7U/qL6mgaPpOP4RQ/5Qxus15n4Q@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1CFkKve001320; Sun, 12 Feb 2006 07:46:20 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1CFkKND001319; Sun, 12 Feb 2006 07:46:20 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1CFkJZs001314 for ; Sun, 12 Feb 2006 07:46:19 -0800 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1CFk2Ha009276; Sun, 12 Feb 2006 17:46:02 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1CFjseq009261; Sun, 12 Feb 2006 17:45:55 +0200 Date: Sun, 12 Feb 2006 17:45:54 +0200 (EET) From: Pekka Savola To: Sam Hartman cc: Paul Hoffman , iesg@ietf.org, RJ Atkinson , newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] definition of 'feature'; reasons to advance In-Reply-To: Message-ID: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 12:55:06 2006 on mailapps X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 22:55:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk On Sat, 11 Feb 2006, Sam Hartman wrote: >>>>>> "Paul" == Paul Hoffman writes: > > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. > > Testing every should and must is not required. You need to test every > protocol feature. Depends on what you call a 'feature'. For example, a protocol might have a MUST discard clause for certain malformed, insecure or spoofed packets. If an implementation under testing does not implement that MUST, the outcome of the testing might be unspecified and we don't really know how compliant implementations would perform. Testing SHOULDs have similar, but slightly different implications: two compliant implementations might (but where at least one doesn't implement a SHOULD) not be enough to know if all the acceptable combinations would work. I think the main issue here the motivation for pushing specs along on the standards track. If we do it to demonstrate that the spec is known to interoperate under rigorous testing and be relevant to be implemented in its entirety, detailed reports could be very useful. If the motivation is to just obtain a status level and/or allow normative referencing by other specs, it is not so useful. With the current 3-level standards track and downref rules, I'd propose that Draft Standards should not require very detailed implementation reports, but that getting to Full Standard should. If we eliminate one step and/or remove downref rules, I'd vote for requiring sufficiently detailed interoperability and implementation reports. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sun Feb 12 11:28:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8K5g-0001pF-6u for newtrk-archive@megatron.ietf.org; Sun, 12 Feb 2006 11:28:48 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28181 for ; Sun, 12 Feb 2006 11:27:03 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/tLwbiAFTB4YeEWShknVhia1AINzOG38w@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1CGQwF2001922; Sun, 12 Feb 2006 08:26:58 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1CGQwtW001921; Sun, 12 Feb 2006 08:26:58 -0800 Received: from execdsl.com (mail.shinkuro.com [216.194.124.237]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1CGQvUR001916 for ; Sun, 12 Feb 2006 08:26:57 -0800 Received: from [71.240.232.61] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12996524; Sun, 12 Feb 2006 09:23:16 -0700 Message-Id: <7.0.1.0.0.20060212112226.0325a248@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 12 Feb 2006 11:26:55 -0500 To: Pekka Savola From: "Joel M. Halpern" Subject: Re: [newtrk] definition of 'feature'; reasons to advance Cc: newtrk@lists.uoregon.edu In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.88/1284/Sun Feb 12 08:00:59 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Pekka, we don't do or require conformance testing. We do not actually ask whether the implementations "conform" to the specification. We ask whether the implementations implement the feature, and whether they interoperate. Features are usually understood to be larger granularity than each individual MUST or SHOULD in the document. (That still produces a lot of features in a protocol like OSPF or BGP.) Specifically, we do not require testing of every boundary condition and error case identified in the RFC for advancement. The description for the testing is usually "thorough", but not "rigorous". We do generally put together test descriptions to make sure we covered all of the options in all of the features. Full standard does not require more testing than draft. It requires more real world experience. Yours, Joel M. Halpern At 10:45 AM 2/12/2006, Pekka Savola wrote: >On Sat, 11 Feb 2006, Sam Hartman wrote: >Testing every should and must is not required. You need to test every >>protocol feature. > >Depends on what you call a 'feature'. For example, a protocol might >have a MUST discard clause for certain malformed, insecure or >spoofed packets. If an implementation under testing does not >implement that MUST, the outcome of the testing might be unspecified >and we don't really know how compliant implementations would >perform. Testing SHOULDs have similar, but slightly different >implications: two compliant implementations might (but where at >least one doesn't implement a SHOULD) not be enough to know if all >the acceptable combinations would work. > >I think the main issue here the motivation for pushing specs along >on the standards track. If we do it to demonstrate that the spec is >known to interoperate under rigorous testing and be relevant to be >implemented in its entirety, detailed reports could be very useful. >If the motivation is to just obtain a status level and/or allow >normative referencing by other specs, it is not so useful. > >With the current 3-level standards track and downref rules, I'd >propose that Draft Standards should not require very detailed >implementation reports, but that getting to Full Standard should. If >we eliminate one step and/or remove downref rules, I'd vote for >requiring sufficiently detailed interoperability and implementation reports. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >. >newtrk resources:_____________________________________________________ >web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html >mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sun Feb 12 21:03:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8T3m-00086r-9B for newtrk-archive@megatron.ietf.org; Sun, 12 Feb 2006 21:03:26 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01882 for ; Sun, 12 Feb 2006 21:01:39 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX181MXq4RBck0mTyt2BqFlVxs25hBsPpqB4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D1vtn5010747; Sun, 12 Feb 2006 17:57:55 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1D1vtRM010746; Sun, 12 Feb 2006 17:57:55 -0800 Received: from exprod6og12.obsmtp.com (exprod6og12.obsmtp.com [64.18.1.24]) by mailapps.uoregon.edu (8.13.5/8.13.5) with SMTP id k1D1vsRu010741 for ; Sun, 12 Feb 2006 17:57:54 -0800 Received: from source ([192.150.11.134]) by exprod6ob12.obsmtp.com ([64.18.5.12]) with SMTP; Sun, 12 Feb 2006 17:57:54 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k1D1vKBl017562 for ; Sun, 12 Feb 2006 17:57:21 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k1D1vpru010189 for ; Sun, 12 Feb 2006 17:57:52 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUL00NXSS4E1L@mailsj-v1.corp.adobe.com> for newtrk@lists.uoregon.edu; Sun, 12 Feb 2006 17:57:50 -0800 (PST) Received: from MasinterT43p ([10.7.241.41]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUL0030RS4DZB@mailsj-v1.corp.adobe.com> for newtrk@lists.uoregon.edu; Sun, 12 Feb 2006 17:57:50 -0800 (PST) Date: Sun, 12 Feb 2006 17:57:23 -0800 From: Larry Masinter Subject: RE: [newtrk] definition of 'feature'; reasons to advance In-reply-to: To: "'Pekka Savola'" , "'Sam Hartman'" Cc: "'Paul Hoffman'" , iesg@ietf.org, "'RJ Atkinson'" , newtrk@lists.uoregon.edu, saag@mit.edu Message-id: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcYv7fPCkrEzS48tQ8GUTl8G6G+BPAAUoCJg X-Virus-Scanned: ClamAV 0.88/1284/Sun Feb 12 08:00:59 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > Testing every should and must is not required. You need to test every > > protocol feature. > > Depends on what you call a 'feature'. For example, a protocol might > have a MUST discard clause for certain malformed, insecure or spoofed > packets. If an implementation under testing does not implement that > MUST, the outcome of the testing might be unspecified and we don't > really know how compliant implementations would perform. Testing > SHOULDs have similar, but slightly different implications: two > compliant implementations might (but where at least one doesn't > implement a SHOULD) not be enough to know if all the acceptable > combinations would work. http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt proposes creating a separate Protocol Feature Set which identifies what constitutes the "features" for a protocol. It is consistent with one-step or two-step or three-step, and might even be a way of migrating gradually between those. Larry . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sun Feb 12 22:55:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Uof-0004UB-9E for newtrk-archive@megatron.ietf.org; Sun, 12 Feb 2006 22:55:59 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08331 for ; Sun, 12 Feb 2006 22:54:12 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/nGsZXD4FlGQTqlaz9UuZ6tjSHrKysMoo@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D3o0O7012790; Sun, 12 Feb 2006 19:50:00 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1D3o0Qo012789; Sun, 12 Feb 2006 19:50:00 -0800 Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D3nrfr012772 for ; Sun, 12 Feb 2006 19:49:54 -0800 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1D3n3gS006206; Mon, 13 Feb 2006 05:49:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 05:49:35 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 05:49:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [newtrk] Re: BCP 61, advancing to draft Date: Mon, 13 Feb 2006 05:49:34 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01A56DB4@esebe100.NOE.Nokia.com> In-Reply-To: <43EC5FB0.4040404@zurich.ibm.com> Thread-Topic: [newtrk] Re: BCP 61, advancing to draft Thread-Index: AcYuJtsD1u5zgjUxQEOlVe+rMBcAagBm7aCg From: To: , Cc: X-OriginalArrivalTime: 13 Feb 2006 03:49:35.0466 (UTC) FILETIME=[817DCCA0:01C63050] X-Virus-Scanned: ClamAV 0.88/1284/Sun Feb 12 08:00:59 2006 on mailapps X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailapps.uoregon.edu id k1D3nsfr012786 Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, > > Does anyone want to work on a better answer to this? > >Yes. draft-carpenter-newtrk-twostep or >draft-loughney-newtrk-one-size-fits-all I've been lurking on this thread, but just had to add 2 cents. In various discussions, I can understand the need for a 3-step process at an abstract level, but practically, I don't see the need. I think that we roughly need something like "This is what recommend to be deployed" and "we think this is right, but there might be a few kinks still left to work out" - which I would propose to be a nice split between "Standard" and "Experimental". There is nothing preventing us from revising "Standard" documents with bug fixes, feature drops, etc. We do that already. There are a large number of protocols that get revised at proposed and stay that way. I guess, at the end of the day, what we do is dependent upon what we want. Most of the discussion on the ISD (and relatated) proposal is that we don't think potential result is worth the effort. John . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 13 03:11:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Ynk-00054o-Eg for newtrk-archive@megatron.ietf.org; Mon, 13 Feb 2006 03:11:16 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24063 for ; Mon, 13 Feb 2006 03:09:29 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18SsFQOvy9oXx73rJVoQpsiemxlb/cBiGM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D88dn0016053; Mon, 13 Feb 2006 00:08:39 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1D88dC2016052; Mon, 13 Feb 2006 00:08:39 -0800 Received: from zeppo.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D88bxn016045 for ; Mon, 13 Feb 2006 00:08:38 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C001E33E7A; Mon, 13 Feb 2006 21:08:31 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28725-04; Mon, 13 Feb 2006 21:08:31 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 37F203414D; Mon, 13 Feb 2006 21:08:29 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 85DAA3774B; Mon, 13 Feb 2006 21:08:29 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F8YlA-0001BN-00; Mon, 13 Feb 2006 21:08:36 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jas@extundo.com, pgut001@cs.auckland.ac.nz Subject: [newtrk] Re: BCP 61, advancing to draft Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, rja@extremenetworks.com, saag@mit.edu In-Reply-To: Message-Id: Date: Mon, 13 Feb 2006 21:08:36 +1300 X-Virus-Scanned: ClamAV 0.88/1284/Sun Feb 12 08:00:59 2006 on mailapps X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Simon Josefsson writes: >I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and >TLS-OpenPGP. All of those combined are buried in the noise floor compared to use of certificates with TLS: TLS-PSK: Really only accepted as something for low-powered devices (although I disagree with this use). TLS-SRP: Amost never used due to patent concerns. TLS-PGP: Never used (or at least there's probably some experimental implementation somewhere, but I'm not aware of it). >Decoupling TLS from PKIX fully would be a good idea. It would also help non- >PKIX TLS mechanisms, which is also good. I think it'd be a good idea too, but it'll never happen in practice. You'd have to convince several million web sites with several hundred million dollars tied up in infrastructure to change, which is never going to happen. Currently every one of them will still do SSLv3 at the drop of a handshake option, which wasn't even an RFC, let alone a standards-track one. Peter. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 13 04:51:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8aMM-0001MN-0q for newtrk-archive@megatron.ietf.org; Mon, 13 Feb 2006 04:51:06 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00680 for ; Mon, 13 Feb 2006 04:49:20 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/dLHn+uA0LOUmOlVu3bgn0TX8DmUgzd1Q@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D9mZlw019016; Mon, 13 Feb 2006 01:48:35 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1D9mZaQ019015; Mon, 13 Feb 2006 01:48:35 -0800 Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1D9mYP1019008 for ; Mon, 13 Feb 2006 01:48:34 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 7ED9E346A9; Mon, 13 Feb 2006 22:48:28 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27608-12; Mon, 13 Feb 2006 22:48:28 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id DC4F83459F; Mon, 13 Feb 2006 22:48:27 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8FE783774B; Mon, 13 Feb 2006 22:48:27 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F8aJv-0001IX-00; Mon, 13 Feb 2006 22:48:35 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jas@extundo.com, pgut001@cs.auckland.ac.nz Subject: [newtrk] Re: BCP 61, advancing to draft Cc: iesg@ietf.org, newtrk@lists.uoregon.edu, rja@extremenetworks.com, saag@mit.edu In-Reply-To: Message-Id: Date: Mon, 13 Feb 2006 22:48:35 +1300 X-Virus-Scanned: ClamAV 0.88/1284/Sun Feb 12 08:00:59 2006 on mailapps X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Simon Josefsson writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>>PKIX TLS mechanisms, which is also good. >> >> I think it'd be a good idea too, but it'll never happen in practice. You'd >> have to convince several million web sites with several hundred million >> dollars tied up in infrastructure to change, which is never going to happen. >> Currently every one of them will still do SSLv3 at the drop of a handshake >> option, which wasn't even an RFC, let alone a standards-track one. > >I don't see how that is related to having TLS depend normatively or >informatively on PKIX. The TLS protocol can be decoupled from the >certificate types used. How? TLS, at least as used with HTTP (which is probably about 99% of it use) is synonymous with X.509 PKI. By "decouple" do you mean replace the current explicit use of X.509 certs with generic language describing an abstract certificate type, and then assume that everyone knows that the abstract certificate type is actually meant to be X.509 even though it's not made explicit? (Incidentally, you run into additional problems with TLS extensions, which reference a pile of X.509 cert mechanisms). Peter. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 13 10:49:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fxO-0004Gz-1Q for newtrk-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:49:42 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02246 for ; Mon, 13 Feb 2006 10:47:56 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+sbN1PyzfIpEfg0yEBK3xU6JuIbAQ2qzU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1DFkWqW023922; Mon, 13 Feb 2006 07:46:32 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1DFkWwM023918; Mon, 13 Feb 2006 07:46:32 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1DFkVwl023906 for ; Mon, 13 Feb 2006 07:46:32 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D2C31E0074; Sun, 12 Feb 2006 15:20:09 -0500 (EST) To: Pekka Savola Cc: Paul Hoffman , iesg@ietf.org, RJ Atkinson , newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] Re: definition of 'feature'; reasons to advance References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> From: Sam Hartman Date: Sun, 12 Feb 2006 15:20:08 -0500 In-Reply-To: (Pekka Savola's message of "Sun, 12 Feb 2006 17:45:54 +0200 (EET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1286/Mon Feb 13 03:41:56 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Remember the goal of the implementation report is to test the specification and make sure it is clear enough to create two interoperable implementations. We are not doing conformance testing; we are not doing interoperability testing of the implementations. We're simply trying to determine if the spec is good enough that you can create interoperable implementations from it. At least when I've asked other IESG members about this it explicitly means that you don't check error paths involving data that a conforming implementation cannot generate. Conformance testing is very useful and the kind of testing we've done can be a useful in developing conformance tests. But please let's not make the job harder than it has to be. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 13 10:52:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8g06-0005JO-OJ for newtrk-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:52:30 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02484 for ; Mon, 13 Feb 2006 10:50:45 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+UAsieg3DRetHbZb5J7UHfGPnUwFISrrg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1DFkWrX023919; Mon, 13 Feb 2006 07:46:32 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1DFkWUS023917; Mon, 13 Feb 2006 07:46:32 -0800 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1DFkVKM023907 for ; Mon, 13 Feb 2006 07:46:32 -0800 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2BA9EE0078; Sun, 12 Feb 2006 21:42:49 -0500 (EST) To: Larry Masinter Cc: "'Pekka Savola'" , "'Paul Hoffman'" , iesg@ietf.org, "'RJ Atkinson'" , newtrk@lists.uoregon.edu, saag@mit.edu Subject: Re: [newtrk] definition of 'feature'; reasons to advance References: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> From: Sam Hartman Date: Sun, 12 Feb 2006 21:42:49 -0500 In-Reply-To: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> (Larry Masinter's message of "Sun, 12 Feb 2006 17:57:23 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1286/Mon Feb 13 03:41:56 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> "Larry" == Larry Masinter writes: Larry> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt Larry> proposes creating a separate Protocol Feature Set which Larry> identifies what constitutes the "features" for a protocol. Larry> It is consistent with one-step or two-step or three-step, Larry> and might even be a way of migrating gradually between Larry> those. As a side note, we found this analysis (based on an early draft of your work) very useful in creating a feature matrix for Kerberos. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 14 09:00:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90ip-0006M8-BW for newtrk-archive@megatron.ietf.org; Tue, 14 Feb 2006 09:00:03 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27629 for ; Tue, 14 Feb 2006 08:58:15 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX192vqLTAu/m0dJKDa7t39eMYbqeZaCi0ug@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1EDvDRg023082; Tue, 14 Feb 2006 05:57:13 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1EDvD30023081; Tue, 14 Feb 2006 05:57:13 -0800 Received: from mtagate4.uk.ibm.com (mtagate4.uk.ibm.com [195.212.29.137]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1EDvBni023071 for ; Tue, 14 Feb 2006 05:57:12 -0800 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k1EDv6l6231590 for ; Tue, 14 Feb 2006 13:57:06 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1EDv88B210982 for ; Tue, 14 Feb 2006 13:57:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k1EDv511023633 for ; Tue, 14 Feb 2006 13:57:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k1EDv5uX023614 for ; Tue, 14 Feb 2006 13:57:05 GMT Received: from zurich.ibm.com (sig-9-145-254-70.de.ibm.com [9.145.254.70]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA45096 for ; Tue, 14 Feb 2006 14:57:04 +0100 Message-ID: <43F1E1AE.4000707@zurich.ibm.com> Date: Tue, 14 Feb 2006 14:57:02 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: New Track Subject: [newtrk] Uplevelling the discussion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1288/Tue Feb 14 01:24:31 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit The BCP 61 thread triggered a new round of discussion about what we might call Basic Newtrk. To be frank, and pointing the finger at nobody (or everybody), we haven't made much progress here. I've asked Scott Bradner to address the question of "where next?" for newtrk in the General Area open meeting in Dallas. We need to figure out a productive way forward, perhaps with very specific but limited objectives. Brian . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 14 14:11:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F95Zz-0002WS-TG for newtrk-archive@megatron.ietf.org; Tue, 14 Feb 2006 14:11:16 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20516 for ; Tue, 14 Feb 2006 14:09:28 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+uJGF7yKpSGrvqlRrIDoR+JAS8yTGL40Q@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1EJ5AgI030282; Tue, 14 Feb 2006 11:05:10 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1EJ5Ac1030281; Tue, 14 Feb 2006 11:05:10 -0800 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1EJ59q5030276 for ; Tue, 14 Feb 2006 11:05:10 -0800 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k1EJ5618018813 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Feb 2006 11:05:09 -0800 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01A56DB4@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01A56DB4@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A14AC74-F80A-4B44-8BBC-4180777FE1EC@mail-abuse.org> Cc: , , Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [newtrk] Re: BCP 61, advancing to draft Date: Tue, 14 Feb 2006 11:05:16 -0800 To: "" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1289/Tue Feb 14 06:36:44 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 12, 2006, at 7:49 PM, wrote: >> >> Yes. draft-carpenter-newtrk-twostep or draft-loughney-newtrk-one- >> size-fits-all > > I've been lurking on this thread, but just had to add 2 cents. In > various discussions, I can understand the need for a 3-step process > at an > abstract level, but practically, I don't see the need. I think > that we roughly need something like "This is what recommend to be > deployed" and "we think this is right, but there might be a few > kinks still left to work out" - which I would propose to be a nice > split between "Standard" and "Experimental". There is nothing > preventing us from revising "Standard" documents with bug fixes, > feature drops, etc. We do that already. There are a large number > of protocols that get revised at proposed and stay that way. > > I guess, at the end of the day, what we do is dependent upon what > we want. Most of the discussion on the ISD (and relatated) proposal > is that we > don't think potential result is worth the effort. As RFC documents increase in number, and become modified again and again, the increased entropy makes reviewing or understanding what is involved with a particular endeavour increasingly difficult. Down referencing is just one aspect of the problem. A document naming convention or a reference overlay like SRD sits atop the profusion of numbered documents and adds clarity and reference stability. This only needs a directory to publish relational documents by those so motivated. In the case of naming or the named linking of related documents, the overview needed should be minimal. Rather than viewing this problem from the perspective of the auto mechanic who has memorized relevant part numbers, for the typical person looking for a part however, user-friendly listings are extremely helpful. The named organization effort would be done one time, but the benefits are accumulative. Even the mechanic has been known to overlook a part number update. -Doug . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Wed Feb 15 08:16:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MWK-0007NC-J7 for newtrk-archive@megatron.ietf.org; Wed, 15 Feb 2006 08:16:36 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07780 for ; Wed, 15 Feb 2006 08:14:48 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+wZdfHxTTghfd6wtMEwaxOgksfIvC71fU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1FD7k6b019657; Wed, 15 Feb 2006 05:07:46 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1FD7kFf019656; Wed, 15 Feb 2006 05:07:46 -0800 Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1FD7eWK019651 for ; Wed, 15 Feb 2006 05:07:40 -0800 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1FD7DSC020549; Wed, 15 Feb 2006 15:07:15 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 15:06:58 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 15:06:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [newtrk] Re: BCP 61, advancing to draft Date: Wed, 15 Feb 2006 15:06:57 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869C21@esebe100.NOE.Nokia.com> In-Reply-To: <0A14AC74-F80A-4B44-8BBC-4180777FE1EC@mail-abuse.org> Thread-Topic: [newtrk] Re: BCP 61, advancing to draft Thread-Index: AcYxmbQRy7bo2ifTQgyyr/mnIUqwdgAlpCzg From: To: Cc: , , X-OriginalArrivalTime: 15 Feb 2006 13:06:57.0972 (UTC) FILETIME=[B39ABF40:01C63230] X-Virus-Scanned: ClamAV 0.88/1289/Tue Feb 14 06:36:44 2006 on mailapps X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailapps.uoregon.edu id k1FD7fWK019653 Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 8bit Doug >> I guess, at the end of the day, what we do is dependent upon what we >> want. Most of the discussion on the ISD (and relatated) proposal is >> that we don't think potential result is worth the effort. > >As RFC documents increase in number, and become modified again >and again, the increased entropy makes reviewing or >understanding what is involved with a particular endeavour >increasingly difficult. Down referencing is just one aspect >of the problem. A document naming convention or a reference >overlay like SRD sits atop the profusion of numbered documents >and adds clarity and reference stability. This only needs a >directory to publish relational documents by those so >motivated. In the case of naming or the named linking of >related documents, the overview needed should be minimal. > >Rather than viewing this problem from the perspective of the >auto mechanic who has memorized relevant part numbers, for the >typical person looking for a part however, user-friendly >listings are extremely helpful. The named organization effort >would be done one time, but the benefits are accumulative. >Even the mechanic has been known to overlook a part number update. I think that's what we have been thinking wrt the ISD/SRD proposals, but I don't think we've had great buy-in from the larger community. John . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Wed Feb 15 12:44:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Qhw-0007Ux-OA for newtrk-archive@megatron.ietf.org; Wed, 15 Feb 2006 12:44:53 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15770 for ; Wed, 15 Feb 2006 12:43:05 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18yqGIJTfjB3Z+mwIPIJxXN+7eKqIaiGUk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1FHZtvq025335; Wed, 15 Feb 2006 09:35:55 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1FHZtc8025334; Wed, 15 Feb 2006 09:35:55 -0800 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1FHZsVM025329 for ; Wed, 15 Feb 2006 09:35:54 -0800 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k1FHZrqt001698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Feb 2006 09:35:54 -0800 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869C21@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869C21@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: NEWTRK Mailing List Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [newtrk] Re: BCP 61, advancing to draft Date: Wed, 15 Feb 2006 09:35:59 -0800 To: "" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1289/Tue Feb 14 06:36:44 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 15, 2006, at 5:06 AM, wrote: > > > I think that's what we have been thinking wrt the ISD/SRD > proposals, but I don't think we've had great buy-in from the larger > community. At the last newtrk meeting, the majority of those attending did see merit in the SRD proposal. Since then, DTD and XSLT script have been published with the draft to auto-generate HTML versions of the SRD overlays, utilizing present xml bibliography databases. This draft is at the beginning of its development. From the first meeting, issues remaining were whether there should be an option to add notes. Details related to naming and numbering should receive greater review as well. Once newtrk made these decisions, setting up a repository for both working and accepted SRD overlays would allow the experiment to begin. Only then, allowing SRD overlays to provide a _real_ service, would buy-in across the larger community be discernible, especially when the needed tools and IETF directories are made available. The next IETF meetings dropped newtrk from the schedule. Why was this SRD effort curtailed when the WG seemed in favor of pursing the concept? Surely, IESG overview of simple SRD overlays would not be too demanding. These overlays should even assist with their other duties. -Doug . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 16 10:26:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9l1a-00073J-F6 for newtrk-archive@megatron.ietf.org; Thu, 16 Feb 2006 10:26:30 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03076 for ; Thu, 16 Feb 2006 10:24:41 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+HV9AZLydg0VXoFHZXZ1kER6GDUtT1XGI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1GFKPLq020099; Thu, 16 Feb 2006 07:20:25 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1GFKPRC020098; Thu, 16 Feb 2006 07:20:25 -0800 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1GFKMuR020093 for ; Thu, 16 Feb 2006 07:20:24 -0800 Received: from sandelman.ottawa.on.ca (CPE0006b123a026-CM0011aea1b6fc.cpe.net.cable.rogers.com [65.49.207.194]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1GFK9p29280 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 16 Feb 2006 10:20:15 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 91D8D3AD9C; Thu, 16 Feb 2006 10:20:09 -0500 (EST) To: Jari Arkko cc: newtrk@lists.uoregon.edu, saag@mit.edu Subject: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Jari Arkko of "Mon, 13 Feb 2006 14:32:42 +0200." <43F07C6A.5010807@piuha.net> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <43F07C6A.5010807@piuha.net> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 16 Feb 2006 10:20:09 -0500 Message-ID: <19879.1140103209@sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: ClamAV 0.88/1290/Thu Feb 16 01:14:53 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jari" == Jari Arkko writes: Jari> o Desire to address a number of issues in one go. For Jari> instance, produce a "bis" revision along with adding features Jari> 1, 2, and 3. I would suggest a stepwise approach would be Jari> better. Take small steps, but take them often. As an example, As I've said before --- we made this mistake with IKEv1->IKEv2. Jari> o Lack of editor and other participant resources for the Jari> work. I suspect timely completion of spec revisions has an Jari> impact on the availability of people to do the work. For There is another factor here -- it's hard to make a small change to an existing document because the .xml file isn't available. (Or may never have existed). And the nroff source that the rfc-editor used, won't match. Jari> o Lack of interoperability testing of all features. If this Jari> situation persists, I don't think its just a question about Jari> interop events or even funding. Its a more fundamental issue Jari> about specs matching the needs of the world. Personally, I Interop events and funding *ARE* important issues. Lots of people want open source reference implementations --- it's hard to fund this. Even if you assume the people are free (they aren't), you can't afford to attend meetings, interop events. etc. without funding. Jari> like small base specs accompanied with a number of optional Jari> extensions. They are a bit harder to read, but the tradeoff Jari> wrt publication speed is well worth it. I agree strongly. Make people plan for new features being added, rather than adding them. Mostly, we do a good job here, but not always. Jari> I would also suggest pursuing the IKEv2 clarifications (is the Jari> result a "bis"?) work as soon as possible, and not adding new Jari> features during that process. I agree. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ/SYHICLcPvd0N1lAQLPnQf/cm803pjwp8Amgo/ofy87a0jFuHHIjX2t GuiHE0E1UKFQ029C8J92GzxfYAfXdCDxS7UhuM/xnpF81+ohfXurFwq5ttjsY9Du 7Hj9Mmh60DoaPwcxZpegllm4O6RtU9s7wj2UqE2Kv49FfDkwyNkhWGwtwYoZyEIx HKv1XAuhVt+xHUi1mkZUQ08/g+lQ2a2vvIHn6J6CnyuMNc+8RNbQjbaHavH0Qs/p sB162ewqeVlzcjZpLC62K9O6ODMlifgixVamumFH5qAJLAQfQ1UTH/USNnNInSNQ f0PEtBOmZWLqGv7EK95gr/BUlC69S7XoBoRVeKgz9Det69WjnxYcTA== =9gkP -----END PGP SIGNATURE----- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 09:47:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6tH-000101-Nn for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 09:47:23 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14256 for ; Fri, 17 Feb 2006 09:45:34 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/TCeZRUPku2vpiGX3PMIvbYzS0TRyMwk8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HEiZhj001766; Fri, 17 Feb 2006 06:44:35 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HEiZgI001765; Fri, 17 Feb 2006 06:44:35 -0800 Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.29.151]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HEiIWX001759 for ; Fri, 17 Feb 2006 06:44:35 -0800 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1HEiCHm168894 for ; Fri, 17 Feb 2006 14:44:12 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1HEiIVs233490 for ; Fri, 17 Feb 2006 15:44:18 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1HEiBWo002005 for ; Fri, 17 Feb 2006 15:44:12 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1HEiB6j001966; Fri, 17 Feb 2006 15:44:11 +0100 Received: from zurich.ibm.com (sig-9-146-216-246.de.ibm.com [9.146.216.246]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA38614; Fri, 17 Feb 2006 15:44:10 +0100 Message-ID: <43F5E132.7010706@zurich.ibm.com> Date: Fri, 17 Feb 2006 15:44:02 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Douglas Otis CC: "" , NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft References: <1AA39B75171A7144A73216AED1D7478D01869C21@esebe100.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Douglas Otis wrote: ... > The next IETF meetings dropped newtrk from the schedule. Why was this > SRD effort curtailed when the WG seemed in favor of pursing the > concept? Surely, IESG overview of simple SRD overlays would not be too > demanding. These overlays should even assist with their other duties. SRDs haven't been discussed in the IESG. Right now we need to figure out a higher level view of where newtrk should go, and I've asked Scott Bradner to address that in the General Area open meeting planned for Dallas. Brian . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 10:56:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7xy-0003jw-1F for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:56:18 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02761 for ; Fri, 17 Feb 2006 10:54:28 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19lXc4MD2EvQLkW+Mtn0q44mm5lH1ze+wQ@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HFl9o6002913; Fri, 17 Feb 2006 07:47:09 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HFl99e002912; Fri, 17 Feb 2006 07:47:09 -0800 Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HFl9Ye002902 for ; Fri, 17 Feb 2006 07:47:09 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2006 10:47:04 -0500 X-IronPort-AV: i="4.02,124,1139202000"; d="scan'208"; a="82627294:sNHT29147948" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1HFkrPM020509; Fri, 17 Feb 2006 10:46:53 -0500 (EST) Message-Id: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> To: Brian E Carpenter cc: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft In-reply-to: Your message of Fri, 17 Feb 2006 15:44:02 +0100. <43F5E132.7010706@zurich.ibm.com> Reply-To: erosen@cisco.com MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Feb 2006 10:46:53 -0500 From: Eric Rosen X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk > Right now we need to figure out a higher level view of where newtrk should > go, How about shutting it down due to lack of productivity? I guess I'd like to understand why a new "higher level view of where newtrk should go" is going to be any more effective than the old view. Newtrk has demonstrated all the worst "design by committee" problems. Every possible point of view seems to have a constituency, and since there are no technical facts in dispute, there is no way to determine, with any sort of objectivity, who is right. The initial goal was to simplify the official process and make it more like what we really do. Naturally, many of the proposals ended up trying to make it even more complicated, by adding additional layers (workgroup snapshort, srds, etc.). Of course, there was the very productive effort to go through all the telnet options and figure out which ones need to be reclassified as historical ;-) I'm sure the Internet is working much better as a result of that effort. This has really been a classic case of a WG that runs wild (even if in circles) and cannot maintain its focus on the problem that needs to be solved. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 11:30:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8VD-0004lq-Nh for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 11:30:39 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07439 for ; Fri, 17 Feb 2006 11:28:50 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18C46RpK4eYIABi7gZoj1Mzz6rll6MLlr0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HGPZ0m003933; Fri, 17 Feb 2006 08:25:35 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HGPZMl003932; Fri, 17 Feb 2006 08:25:35 -0800 Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HGPYvB003927 for ; Fri, 17 Feb 2006 08:25:34 -0800 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc12) with SMTP id <20060217162528012005ia2ge>; Fri, 17 Feb 2006 16:25:28 +0000 Message-ID: <059801c633de$8b5c8310$66087c0a@china.huawei.com> From: "Spencer Dawkins" To: "NEWTRK Mailing List" References: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> Subject: Re: [newtrk] Re: BCP 61, advancing to draft Date: Fri, 17 Feb 2006 10:23:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: "Eric Rosen" >> Right now we need to figure out a higher level view of where newtrk >> should >> go, > > How about shutting it down due to lack of productivity? I wish Eric's suggestion was less reasonable than it is, but it's a reasonable suggestion. (rest of justified rant deleted) So, I guess the metaquestion would be, do we actually need to make any changes to the standards process at all, or is simply ignoring the inconvenient parts of the current process the best path forward? And the meta-metaquestion would be, do people look to IETF for standards, or simply for specifications? Thanks, Spencer . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 11:54:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8sQ-0003nM-Nu for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 11:54:38 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09676 for ; Fri, 17 Feb 2006 11:52:48 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19DwG4G4d+hCf0JRDjKwCy7jF6d7YGlZGs@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HGqKfS004643; Fri, 17 Feb 2006 08:52:20 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HGqKFs004642; Fri, 17 Feb 2006 08:52:20 -0800 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HGqKaN004635 for ; Fri, 17 Feb 2006 08:52:20 -0800 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2006 08:52:15 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="406613714:sNHT30714712" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HGqEWF004257; Fri, 17 Feb 2006 08:52:14 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp310.cisco.com [10.61.65.54]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1HGtBBc021582; Fri, 17 Feb 2006 08:55:11 -0800 Message-ID: <43F5FF3A.1030007@cisco.com> Date: Fri, 17 Feb 2006 17:52:10 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: erosen@cisco.com CC: Brian E Carpenter , NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft References: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> In-Reply-To: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=573; t=1140195314; x=1140627514; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[newtrk]=20Re=3A=20BCP=2061,=20advancing=20to=20draft |To:=20erosen@cisco.com; X=v=3Dmtcc.com=3B=20h=3D6JxtHiD8rD3XPzHOq6IWAiX7vBQ=3D; b=UzzpvINTKIYKtFKWK23qPO55T04Vl1BfEx4vKI6PigWFnzzxIE9Bqmo925bAxngwpjydebFJ EkVQPsRKfzaM32Jzr7haIn3PpbpDUiGygTDXzFdKlABzcOemFSyr1Ncn3jUhf4fqj2VjidwZtWm jEPeL9UDWTIQGPUBXA1+bGmw=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: > How about shutting it down due to lack of productivity? Well, it's not been entirely unproductive. And as you point out, some of the problem lies with the IESG's inability to take any sort of responsibility in this space. They think it ain't broke, by in large. I think there are a few obvious breaks. 2026 is in dire need of a rewrite. Either there is a distinction between PS and standard or there is not. Either the IESG follows the rules we set out in that document or we should remove them. The problems aren't technical. Eliot . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 14:53:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABfL-0000lE-NJ for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 14:53:24 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28603 for ; Fri, 17 Feb 2006 14:51:30 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19m0AviFi+K3+pL48K1oU5ngd3SSzmiP7k@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HJlduY009620; Fri, 17 Feb 2006 11:47:39 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HJldFR009619; Fri, 17 Feb 2006 11:47:39 -0800 Received: from mail76.messagelabs.com (mail76.messagelabs.com [216.82.240.83]) by mailapps.uoregon.edu (8.13.5/8.13.5) with SMTP id k1HJlcGg009614 for ; Fri, 17 Feb 2006 11:47:39 -0800 X-VirusChecked: Checked X-Env-Sender: rsnively@Brocade.COM X-Msg-Ref: server-12.tower-76.messagelabs.com!1140205657!69224767!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 16506 invoked from network); 17 Feb 2006 19:47:37 -0000 Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112) by server-12.tower-76.messagelabs.com with SMTP; 17 Feb 2006 19:47:37 -0000 Received: from hq-ex-5.corp.brocade.com (hq-ex-5 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 41C0514260; Fri, 17 Feb 2006 11:47:37 -0800 (PST) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-5.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Feb 2006 11:47:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [newtrk] Re: BCP 61, advancing to draft Date: Fri, 17 Feb 2006 11:47:36 -0800 Message-ID: <66CFE0CA1DDEB54493E63A2C7C529246024C665A@hq-ex-6.brocade.com> Thread-Topic: [newtrk] Re: BCP 61, advancing to draft Thread-Index: AcYz2Y7BHgPEO0XMTEynACAfAJYSRAAIFJrw From: "Robert Snively" To: , "Brian E Carpenter" Cc: "NEWTRK Mailing List" X-OriginalArrivalTime: 17 Feb 2006 19:47:37.0229 (UTC) FILETIME=[00F1C3D0:01C633FB] X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailapps.uoregon.edu id k1HJldGg009616 Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 8bit The basic problem is that these problems are not going to go away. There is either a procedure that works and is followed, or there is a set of customs that are ignored as desired. What we have documented is the former, and what we do is the latter. Why not simply document the customs as the new procedures. That would be basically a one step standards process with the possibility of converting some documents to a "maintenance" or a "super-approved" state. This one step standards process is to some extent a consequence of the concept of short-term focused working groups. Without a longer term group, there is little capability to carry on subsequent standardization steps. So whether we close newtrk or not, the problems will remain until some action fixes them. Bob -----Original Message----- From: owner-newtrk@lists.uoregon.edu [mailto:owner-newtrk@lists.uoregon.edu] On Behalf Of Eric Rosen Sent: Friday, February 17, 2006 7:47 AM To: Brian E Carpenter Cc: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft > Right now we need to figure out a higher level view of where newtrk should > go, How about shutting it down due to lack of productivity? I guess I'd like to understand why a new "higher level view of where newtrk should go" is going to be any more effective than the old view. Newtrk has demonstrated all the worst "design by committee" problems. Every possible point of view seems to have a constituency, and since there are no technical facts in dispute, there is no way to determine, with any sort of objectivity, who is right. The initial goal was to simplify the official process and make it more like what we really do. Naturally, many of the proposals ended up trying to make it even more complicated, by adding additional layers (workgroup snapshort, srds, etc.). Of course, there was the very productive effort to go through all the telnet options and figure out which ones need to be reclassified as historical ;-) I'm sure the Internet is working much better as a result of that effort. This has really been a classic case of a WG that runs wild (even if in circles) and cannot maintain its focus on the problem that needs to be solved. . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 15:57:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACfe-0007tP-NA for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 15:57:42 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04784 for ; Fri, 17 Feb 2006 15:55:53 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+ejBet+xe5xvcRFMEeN4CS1t2gRxcHKP4@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HKsbKr011156; Fri, 17 Feb 2006 12:54:37 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HKsbmN011155; Fri, 17 Feb 2006 12:54:37 -0800 Received: from smtpout1.bayarea.net (smtpout1.BAYAREA.NET [209.128.95.10]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HKsb5S011150 for ; Fri, 17 Feb 2006 12:54:37 -0800 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k1HKsk1l020501 for ; Fri, 17 Feb 2006 12:54:46 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k1HKsaPU010366; Fri, 17 Feb 2006 12:54:36 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k1HKsZ5O010362; Fri, 17 Feb 2006 12:54:36 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 17 Feb 2006 12:54:35 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft In-Reply-To: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> <059801c633de$8b5c8310$66087c0a@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk >>>>> On Fri, 17 Feb 2006, Eric Rosen wrote: Eric> > Right now we need to figure out a higher level view of where Eric> > newtrk should go, Eric> Eric> How about shutting it down due to lack of productivity? >>>>> On Fri, 17 Feb 2006, Spencer Dawkins wrote: Spencer> I wish Eric's suggestion was less reasonable than it is, but Spencer> it's a reasonable suggestion. I am afraid that I have to agree. Eric> [ ... ] The initial goal was to simplify the official process Eric> and make it more like what we really do. Naturally, many of the Eric> proposals ended up trying to make it even more complicated, by Eric> adding additional layers (workgroup snapshort, srds, etc.). There is exactly one proposal on the table that would simplify the process and make it more like what we really do, and that proposal is draft-loughney-newtrk-one-size-fits-all. I think the WG should either adopt that proposal and send it out for IETF last call or else admit defeat and close up shop. //cmh . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 16:51:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADVo-000232-S8 for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 16:51:37 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16622 for ; Fri, 17 Feb 2006 16:49:47 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+9II1mRYLDIKNm8wnvPyk+Bfwi7E6sY+s@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HLhVIM012278; Fri, 17 Feb 2006 13:43:31 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HLhVsA012277; Fri, 17 Feb 2006 13:43:31 -0800 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HLhVn3012272 for ; Fri, 17 Feb 2006 13:43:31 -0800 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k1HLhTdB020014 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 13:43:29 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24533ABD-DB06-49E3-A47D-8BA7B0754E5A@mail-abuse.org> Cc: NEWTRK Mailing List Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [newtrk] Re: BCP 61, advancing to draft Date: Fri, 17 Feb 2006 13:43:40 -0800 To: "C. M. Heard" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 17, 2006, at 12:54 PM, C. M. Heard wrote: >>> On Fri, 17 Feb 2006, Eric Rosen wrote: >>> On Fri, 17 Feb 2006, Spencer Dawkins wrote: > > Eric> > Right now we need to figure out a higher level view of where > Eric> > newtrk should go, > Eric> > Eric> How about shutting it down due to lack of productivity? > > Spencer> I wish Eric's suggestion was less reasonable than it is, but > Spencer> it's a reasonable suggestion. > > I am afraid that I have to agree. > > Eric> [ ... ] The initial goal was to simplify the official process > Eric> and make it more like what we really do. Naturally, many of the > Eric> proposals ended up trying to make it even more complicated, by > Eric> adding additional layers (workgroup snapshort, srds, etc.). sigh. > There is exactly one proposal on the table that would simplify the > process and make it more like what we really do, and that proposal > is draft-loughney-newtrk-one-size-fits-all. I think the WG should > either adopt that proposal and send it out for IETF last call or > else admit defeat and close up shop. Tracking document relationships with the SRD overlay conveys the endeavour affected by a proposed change. Clearly, the present document classification has not been effective at communicating the status for a set of documents as related to a particular endeavour. Within a particular endeavour, there might be a stable set of documents and a newer set of documents proposing a modification to overcome some issue. With the SRD approach, there is a way to ensure these different sets of documents can be discerned. Rating those document sets should be based upon interoperability, which makes the two-step approach appear more appropriate. As any document can appear within multiple sets of documents at any point in time, these two ratings would be best done at the set level (the SRD level). This would then suggest, for RFCs, fewer distinctions are needed. Even the SRD overlay provides a category for experimental components within the set. I could agree with both the one-size at the RFC, and the two-step at the SRD. The SRD overlay is not complicated. Newtrk should ensure this scheme is clear and straight forward. Providing the tools to start this transition does not need to wait for documents that define one-size or two-step however. -Doug . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 17 19:01:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAFXl-0005hA-Nv for newtrk-archive@megatron.ietf.org; Fri, 17 Feb 2006 19:01:45 -0500 Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28175 for ; Fri, 17 Feb 2006 18:59:57 -0500 (EST) Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19MzfIArC51jMldupoii2tjK9scTfqAhOE@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HNujtG015079; Fri, 17 Feb 2006 15:56:45 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1HNujVf015078; Fri, 17 Feb 2006 15:56:45 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1HNuiNr015071 for ; Fri, 17 Feb 2006 15:56:44 -0800 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k1HNIt705554 for ; Fri, 17 Feb 2006 15:18:55 -0800 X-mProtect: <200602172318> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164200.americas.nokia.com (10.241.164.200, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdWD9u9h; Fri, 17 Feb 2006 15:18:53 PST Message-ID: <43F662AA.8010503@iprg.nokia.com> Date: Fri, 17 Feb 2006 15:56:26 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft References: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> <43F5FF3A.1030007@cisco.com> In-Reply-To: <43F5FF3A.1030007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, I've been lurking on the mailing list for all these many months. It seems there is rough consensus that the standardization process is broken. I certainly think so. If it cannot be fixed, then I guess there are even more problems than I thought. Regards, Charlie P. Eliot Lear wrote: >Eric Rosen wrote: > > >>How about shutting it down due to lack of productivity? >> >> >Well, it's not been entirely unproductive. And as you point out, some >of the problem lies with the IESG's inability to take any sort of >responsibility in this space. They think it ain't broke, by in large. >I think there are a few obvious breaks. 2026 is in dire need of a >rewrite. Either there is a distinction between PS and standard or there >is not. Either the IESG follows the rules we set out in that document >or we should remove them. The problems aren't technical. > >Eliot > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Sat Feb 18 12:10:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVbj-0004tk-0B for newtrk-archive@lists.ietf.org; Sat, 18 Feb 2006 12:10:55 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAVWp-0003Xk-Dz for newtrk-archive@lists.ietf.org; Sat, 18 Feb 2006 12:05:51 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FAUe2-0002eM-U9 for newtrk-archive@lists.ietf.org; Sat, 18 Feb 2006 11:09:16 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+S2twwVUW5m/snKa3R0kazTkLwq7mKb5Y@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1IFvKmF029538; Sat, 18 Feb 2006 07:57:20 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1IFvKk6029537; Sat, 18 Feb 2006 07:57:20 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1IFvJDt029532 for ; Sat, 18 Feb 2006 07:57:19 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FAUSP-000BpT-9c; Sat, 18 Feb 2006 10:57:13 -0500 Date: Sat, 18 Feb 2006 10:57:12 -0500 From: John C Klensin To: Spencer Dawkins cc: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft Message-ID: <3249B8287475A08183ED7611@p3.JCK.COM> In-Reply-To: <059801c633de$8b5c8310$66087c0a@china.huawei.com> References: <200602171546.k1HFkrPM020509@rtp-core-1.cisco.com> <059801c633de$8b5c8310$66087c0a@china.huawei.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1292/Fri Feb 17 01:39:02 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --On Friday, 17 February, 2006 10:23 -0600 Spencer Dawkins wrote: > From: "Eric Rosen" >... >> How about shutting it down due to lack of productivity? > > I wish Eric's suggestion was less reasonable than it is, but > it's a reasonable suggestion. >... > So, I guess the metaquestion would be, do we actually need to > make any changes to the standards process at all, or is simply > ignoring the inconvenient parts of the current process the > best path forward? I disagree. I think the critical-path metaquestion is "is it possible to make significant and substantive changes to the standards process without first making significant and substantive changes to the process by which standards process changes are reviewed and approved"? If the answer is "yes", then we need to look elsewhere for the causes of paralysis in newtrk, perhaps looking at your proposed metaquestion above. If the answer is "no", then we should either give up or start looking at some of the more radical reorganizational proposals that have gone quietly into limbo. john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 20 02:00:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB51t-0006ko-0p for newtrk-archive@lists.ietf.org; Mon, 20 Feb 2006 02:00:17 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB51r-0004JV-K2 for newtrk-archive@lists.ietf.org; Mon, 20 Feb 2006 02:00:17 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18tNiFEtZZWsdruFZkFfbxD2+kWgnJc+tU@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1K6vsmH003423; Sun, 19 Feb 2006 22:57:54 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1K6vsvi003422; Sun, 19 Feb 2006 22:57:54 -0800 Received: from smtpout1.bayarea.net (smtpout1.bayarea.net [209.128.95.10]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1K6vsxY003417 for ; Sun, 19 Feb 2006 22:57:54 -0800 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k1K6uf5H029503 for ; Sun, 19 Feb 2006 22:58:04 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k1K5l6xO001960; Sun, 19 Feb 2006 21:47:06 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k1K5l5Z0001957; Sun, 19 Feb 2006 21:47:06 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 19 Feb 2006 21:47:05 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: NEWTRK Mailing List Subject: Re: [newtrk] Re: BCP 61, advancing to draft In-Reply-To: <43F82E6D.7030509@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88/1293/Sun Feb 19 08:40:25 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Sun, 19 Feb 2006, Brian E Carpenter wrote: > Well, I politely disagree, because there is also the twostep proposal > around, which I am hoping will shortly reappear with a new editor. > > My belief is that twostep is closer to the consensus that prevailed > at the newtrk BOF, i.e. it keeps the "running code" notion alive > but without creating unrealistic expectations. > > However, I'd certainly like to see a real debate between these > two approaches, which we've never had. Two points: 1.) What we do today, most of the time, to put stuff to PS and leave it there. Ergo, one-size-fits-all is closer to prevailing practice that twostep. 2.) We still have the ludicrous situation of stuff like IANA procedures sometimes being put up for PS, when it should be BCP, since it cannot in principle enjoy multiple implementations. I pointed out an example recently on this list. one-size-fits-all cures this problem neatly. 3.) I recently pointed out some examples in the MIB area where the multistep process resulted in fractured specs or needed work not getting done. one-size-fits-all cures this problem, too. The "running code" notion sounds good, but we don't really practice it most of the time, have a hard time figuring out how in certain cases, and in other cases shoot ourselves (or the community) in the foot when we try. We have a model of what we _can_ do. That's one-size-fits-all. Let's put it down on paper and get back to work. //cmh > Spencer Dawkins wrote: > >[C. M. Heard wrote:] > >> There is exactly one proposal on the table that would simplify the > >> process and make it more like what we really do, and that proposal > >> is draft-loughney-newtrk-one-size-fits-all. I think the WG should > >> either adopt that proposal and send it out for IETF last call or > >> else admit defeat and close up shop. > > > > > > Hi, John, > > > > To be perfectly correct at this time, our draft would be a proposal > > UNDER the table, since it expired in January. > > > > Do you still have the XML around for a respin? I'm not finding my own > > copy (sorry!). > > > > Spencer > > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 23 03:21:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCBjC-00013e-D9 for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 03:21:34 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCBjB-0006TL-2M for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 03:21:34 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/x/CjX1l10ovZti1W+SahjnVrtGM53Yg0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1N8G50K026921; Thu, 23 Feb 2006 00:16:05 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1N8G5np026920; Thu, 23 Feb 2006 00:16:05 -0800 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1N8G4Ub026915 for ; Thu, 23 Feb 2006 00:16:05 -0800 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F36B259714 for ; Thu, 23 Feb 2006 09:14:36 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11743-09 for ; Thu, 23 Feb 2006 09:14:33 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C5A325970F for ; Thu, 23 Feb 2006 09:14:33 +0100 (CET) Date: Thu, 23 Feb 2006 09:15:47 +0100 From: Harald Tveit Alvestrand To: newtrk@lists.uoregon.edu Subject: [newtrk] An idea for process document handling Message-ID: <29ED6B7F272FD3648D425B89@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========3C26CDFC4EDF1776C94E==========" X-Virus-Scanned: ClamAV 0.88/1298/Wed Feb 22 12:50:12 2006 on mailapps X-Virus-Scanned: by amavisd-new at alvestrand.no X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --==========3C26CDFC4EDF1776C94E========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I don't think this is strictly a newtrk item, but many of the people who=20 are interested congregate here.... I posted a process experiment idea for handling "standing" documents in the = IETF as draft-alvestrand-ipod-00.txt In that document, I proposed the IETF list as the proper venue for=20 discussing that document. YMMV. Comments are welcome! Harald --==========3C26CDFC4EDF1776C94E========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD/W80OMj+2+WY0F4RAh4FAKDntAL3SegVCubZCpXkgywrX1zxVQCg0saA lGebNCgJACQ7Q7RiwmkpKuU= =sWHw -----END PGP SIGNATURE----- --==========3C26CDFC4EDF1776C94E==========-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 23 15:52:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNRe-0005pu-Ng for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 15:52:14 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCNRe-0004ab-88 for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 15:52:14 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1800GCu8TmVHOzIv/Y7ldIIBEV5JsZakjY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1NKo8cN011182; Thu, 23 Feb 2006 12:50:08 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1NKo8Bh011181; Thu, 23 Feb 2006 12:50:08 -0800 Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1NKo8gq011165 for ; Thu, 23 Feb 2006 12:50:08 -0800 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1NKo10e027336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCNPV-0003D7-S3; Thu, 23 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: newtrk@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [newtrk] I-D ACTION:draft-ietf-newtrk-promotion-00.txt Message-Id: Date: Thu, 23 Feb 2006 15:50:01 -0500 X-Virus-Scanned: ClamAV 0.88/1300/Thu Feb 23 07:55:11 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF. Title : Cleaning the Attic II: Promoting Marketplace-approved Standards Author(s) : J. Klensin, S. Dawkins Filename : draft-ietf-newtrk-promotion-00.txt Pages : 11 Date : 2006-2-23 Historically, Internet Standards have been characterized by three primary criteria: the specifications are stable, implementations of them have been demonstrated to be interoperable, and they have achieved sufficient deployment to be considered useful. The IETF has developed specific rules for determining whether those criteria have been met, but the rules and their implementation have sometimes not adequately reflected those underlying criteria. The result has been that the application of the rules has not resulted in STDs for all protocols that meet the underlying criteria. This document proposes a process experiment to reclassify standards-track documents whose interoperability and utility have been demonstrated by the fact of deployment and use in products being used by Internet users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-newtrk-promotion-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-newtrk-promotion-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-newtrk-promotion-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-23144050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-newtrk-promotion-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-newtrk-promotion-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-23144050.I-D@ietf.org> --OtherAccess-- --NextPart-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 23 19:25:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQmI-0001u4-3x for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 19:25:46 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQmG-0004Ui-NV for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 19:25:46 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX182xLX/16540yCPeXK/cMjuV1HMF1NPKcI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O0KeV0018212; Thu, 23 Feb 2006 16:20:40 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1O0Keba018211; Thu, 23 Feb 2006 16:20:40 -0800 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O0Kemg018206 for ; Thu, 23 Feb 2006 16:20:40 -0800 Received: by newdev.harvard.edu (Postfix, from userid 501) id B32FE67F55A; Thu, 23 Feb 2006 19:20:34 -0500 (EST) To: newtrk@lists.uoregon.edu Subject: [newtrk] an alternate standards promotion process Message-Id: <20060224002034.B32FE67F55A@newdev.harvard.edu> Date: Thu, 23 Feb 2006 19:20:34 -0500 (EST) From: sob@harvard.edu (Scott Bradner) X-Virus-Scanned: ClamAV 0.88/1300/Thu Feb 23 07:55:11 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 the following ID is (imo) in charter for newtrk so I agreed with John that it should be published as a newtrk ID to stimulate discussion this publication should not be taken to mean that newtrk has reached consensus on this path (that should be clear since there has yet to be any discussion on it but I thought I would say that just so that noone would misunderstand) ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF. Title : Cleaning the Attic II: Promoting Marketplace-approved Standards Author(s) : J. Klensin, S. Dawkins Filename : draft-ietf-newtrk-promotion-00.txt Pages : 11 Date : 2006-2-23 Historically, Internet Standards have been characterized by three primary criteria: the specifications are stable, implementations of them have been demonstrated to be interoperable, and they have achieved sufficient deployment to be considered useful. The IETF has developed specific rules for determining whether those criteria have been met, but the rules and their implementation have sometimes not adequately reflected those underlying criteria. The result has been that the application of the rules has not resulted in STDs for all protocols that meet the underlying criteria. This document proposes a process experiment to reclassify standards-track documents whose interoperability and utility have been demonstrated by the fact of deployment and use in products being used by Internet users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-newtrk-promotion-00.txt ... . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Thu Feb 23 21:39:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSre-0005xo-0x for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 21:39:26 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCSrc-0000NV-JB for newtrk-archive@lists.ietf.org; Thu, 23 Feb 2006 21:39:26 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+jy48KQC8iohKkLpOmI0ngzgUttsOwpGI@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O2YHBC020939; Thu, 23 Feb 2006 18:34:17 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1O2YH3H020938; Thu, 23 Feb 2006 18:34:17 -0800 Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O2YGvG020933 for ; Thu, 23 Feb 2006 18:34:16 -0800 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k1O2YFiB013437; Thu, 23 Feb 2006 18:34:15 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 18:34:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [newtrk] an alternate standards promotion process Date: Thu, 23 Feb 2006 18:34:08 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792AE98@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [newtrk] an alternate standards promotion process Thread-Index: AcY42Zd4xG+RZMDQRm2Wn4nTzGxCLgAED6bg From: "Hallam-Baker, Phillip" To: "Scott Bradner" , X-OriginalArrivalTime: 24 Feb 2006 02:34:15.0331 (UTC) FILETIME=[CDD32F30:01C638EA] X-Virus-Scanned: ClamAV 0.88/1300/Thu Feb 23 07:55:11 2006 on mailapps X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailapps.uoregon.edu id k1O2YHvG020935 Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a I think you need to start taking a different approach. Present the IESG with a list of the 100 or so DRAFT standards that have been languishing for years. Discuss advancing one spec to STD. Measure the amount of time taken, multiply by the number of remaining standards. Ask IESG if this is really something they think is a valuable use of their time. If they say yes, take the next standard. If the process is reduced to a formality there is no need for NEWTRK. It is also likely that resistance to change will evaporate. > -----Original Message----- > From: owner-newtrk@lists.uoregon.edu > [mailto:owner-newtrk@lists.uoregon.edu] On Behalf Of Scott Bradner > Sent: Thursday, February 23, 2006 7:21 PM > To: newtrk@lists.uoregon.edu > Subject: [newtrk] an alternate standards promotion process > > > the following ID is (imo) in charter for newtrk so I agreed > with John that it should be published as a newtrk ID to > stimulate discussion > > this publication should not be taken to mean that newtrk has > reached consensus on this path (that should be clear since > there has yet to be any discussion on it but I thought I > would say that just so that noone would misunderstand) > > ----- > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the New IETF Standards Track > Discussion Working Group of the IETF. > > Title : Cleaning the Attic II: Promoting > Marketplace-approved Standards > > Author(s) : J. Klensin, S. Dawkins > Filename : draft-ietf-newtrk-promotion-00.txt > Pages : 11 > Date : 2006-2-23 > > Historically, Internet Standards have been characterized by > three primary criteria: the specifications are stable, > implementations of them have been demonstrated to be > interoperable, and they have achieved sufficient deployment > to be considered useful. The IETF has developed specific > rules for determining whether those criteria have been met, > but the rules and their implementation have sometimes not > adequately reflected those underlying criteria. The result > has been that the application of the rules has not resulted > in STDs for all protocols that meet the underlying criteria. > This document proposes a process experiment to reclassify > standards-track documents whose interoperability and utility > have been demonstrated by the fact of deployment and use in > products being used by Internet users. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-newtrk-promotion-00.txt > > ... > . > newtrk resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html > > . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Fri Feb 24 00:55:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVuv-0005j9-1D for newtrk-archive@lists.ietf.org; Fri, 24 Feb 2006 00:55:01 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCVut-00069D-Im for newtrk-archive@lists.ietf.org; Fri, 24 Feb 2006 00:55:01 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1+YDwFCWZml9Nl8alkybRe38f4YM9WsVTM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O5oCFV024049; Thu, 23 Feb 2006 21:50:13 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1O5oCeb024048; Thu, 23 Feb 2006 21:50:12 -0800 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1O5oC5F024043 for ; Thu, 23 Feb 2006 21:50:12 -0800 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCVq9-0003w8-Qz; Fri, 24 Feb 2006 00:50:06 -0500 Date: Fri, 24 Feb 2006 00:50:04 -0500 From: John C Klensin To: "Hallam-Baker, Phillip" cc: newtrk@lists.uoregon.edu Subject: RE: [newtrk] an alternate standards promotion process Message-ID: <6F2EE600A5D9A55DB10FDCC3@p3.JCK.COM> In-Reply-To: <198A730C2044DE4A96749D13E167AD3792AE98@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792AE98@MOU1WNEXMB04. vcorp.ad.vrsn.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.88/1300/Thu Feb 23 07:55:11 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --On Thursday, 23 February, 2006 18:34 -0800 "Hallam-Baker, Phillip" wrote: > I think you need to start taking a different approach. > > Present the IESG with a list of the 100 or so DRAFT standards > that have been languishing for years. Discuss advancing one > spec to STD. Measure the amount of time taken, multiply by the > number of remaining standards. Ask IESG if this is really > something they think is a valuable use of their time. > > If they say yes, take the next standard. If the process is > reduced to a formality there is no need for NEWTRK. It is also > likely that resistance to change will evaporate. I think this is a plausible alternative. I think I prefer what I suggested for a few reasons, but YMMD: (1) I'm actually more concerned about getting things out of Proposed than I am about getting those which are at Draft advanced. Had I been concerned primarily or exclusively about Draft, I would have proposed an even faster approach, e.g., to make a list like the "decruft" list and, for each document that had been in Draft for some time, ask only two questions: (i) has this been significantly deployed for a while? and (ii) have _serious_ problems appeared during that time? If the answer to the first were "yes", and the second "no", then the document advances. No enabling documents, re-analysis, etc. I would actually consider such a proposal complementary to the one that I posted were it not for the observation that a debate about the choices between the two would probably, based on NEWTRK experience, kill both of them. But, if you believe it is the right thing to do, I think you have until 0900 ET Monday to get it written up. (2) I disagree with your hypothesis that, if one specification can be advanced, resistance to change would evaporate (I know that isn't quite what you said -- see below). Were I on the IESG, I would believe that a single document can be advanced at any time if the requirements were met -- it would just be a matter of normal processing of one document. However, faced with an "opportunity" to get a hundred of so within a short time and the further opportunity to evaluate them according to the current procedures and requirements (including the need to evaluate 15-year-old specifications against current criteria -- the earliest Draft Standard I could find on a quick glance that had not been significantly updated or obsoleted is RFC 1184 from Oct 1990), I think I'd get the chills. (3) The decision about the relative priority of advancing current specs versus working on new ones should ultimately be made by the community, not the IESG. Thus far, the community has clearly voted: the IESG has processed every single advance-in-grade proposal it has received, they just have received very few (relative to possibilities) of them. So, ignoring the "automatic review" provisions of RFC 2026 and its predecessors, the reason why we don't have documents advancing is either (i) no one cares enough to do the work or (ii) the work is too burdensome since the level of effort keeps getting higher. One way to look at the posted proposal is that it is an attempt to tease those alternative explanations apart to see what would happen if the burden were reduced of updating documentation and potentially updating protocols because community or IETF expectations have increased. I can't tell if your proposal would make the same test because you haven't constructed a proposal yet. But, as Scott said in his note, this was posted to stimulate discussion. From my point of view, part of that discussion is to determine whether there is actually work to be done to revise or clean up the standard track and whether such work is feasible or if, in practice, we are good at complaining but incapable of actually agreeing on anything ... in the community at large or with the IESG> If the draft and subsequent discussion causes a better idea to surface, that would be great. If the community is more concerned about advancing Draft Standards than with clearing the backlog of Proposed Standards that have clearly been implemented and deployed, I hope we see a concrete proposal, and soon. And, if the community doesn't care enough to reach sufficient consensus on any of these proposals to produce action, well, I think that answers some broader questions with "we deserve the standards process that we have, warts, ignored rules, and all". best, john . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Mon Feb 27 16:19:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpmh-000804-Em for newtrk-archive@lists.ietf.org; Mon, 27 Feb 2006 16:19:59 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpmg-00061k-1C for newtrk-archive@lists.ietf.org; Mon, 27 Feb 2006 16:19:59 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18tExp5jALKhGMLWCsvwkHryEkX16TmmSk@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1RKoFrP020398; Mon, 27 Feb 2006 12:50:15 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1RKoFXQ020397; Mon, 27 Feb 2006 12:50:15 -0800 Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1RKoEId020392 for ; Mon, 27 Feb 2006 12:50:14 -0800 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1RKo10e014246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDpJh-00070L-OX; Mon, 27 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: newtrk@lists.uoregon.edu From: Internet-Drafts@ietf.org Subject: [newtrk] I-D ACTION:draft-ietf-newtrk-docid-00.txt Message-Id: Date: Mon, 27 Feb 2006 15:50:01 -0500 X-Virus-Scanned: ClamAV 0.88/1305/Mon Feb 27 11:07:49 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF. Title : Identifying Standards Track Documents Author(s) : J. Klensin Filename : draft-ietf-newtrk-docid-00.txt Pages : 9 Date : 2006-2-27 In the present Internet Standards Process, stable identifiers for standards, as distinct from documents (for which RFC numbers are sufficient), has become problematic because proportionately few documents reach Full Standard and are assigned STD numbers. Several proposals have been introduced into NEWTRK to address this problem, but only in the context of trying to resolve a number of other issues. In the hope of making some progress on this dimension, this document proposes a change to the standards-track document identifier system only. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-newtrk-docid-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-newtrk-docid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-newtrk-docid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-27103302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-newtrk-docid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-newtrk-docid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27103302.I-D@ietf.org> --OtherAccess-- --NextPart-- . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html From owner-newtrk@lists.uoregon.edu Tue Feb 28 05:56:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2XG-0002pr-B3 for newtrk-archive@lists.ietf.org; Tue, 28 Feb 2006 05:56:54 -0500 Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE2XD-0006o3-Ro for newtrk-archive@lists.ietf.org; Tue, 28 Feb 2006 05:56:54 -0500 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX189q+xGjOMW+kymz8Q5na5Bz01AVKctoiY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1SAmTuk006980; Tue, 28 Feb 2006 02:48:29 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id k1SAmTO8006979; Tue, 28 Feb 2006 02:48:29 -0800 Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [195.212.29.134]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id k1SAmPpq006970 for ; Tue, 28 Feb 2006 02:48:28 -0800 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k1SAmKnk237716 for ; Tue, 28 Feb 2006 10:48:20 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k1SAmU67188330 for ; Tue, 28 Feb 2006 10:48:31 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k1SAmJiu032036 for ; Tue, 28 Feb 2006 10:48:19 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k1SAmJcu032020 for ; Tue, 28 Feb 2006 10:48:19 GMT Received: from zurich.ibm.com (sig-9-146-221-88.de.ibm.com [9.146.221.88]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA35970 for ; Tue, 28 Feb 2006 11:48:18 +0100 Message-ID: <44042A74.1010208@zurich.ibm.com> Date: Tue, 28 Feb 2006 11:48:20 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: newtrk@lists.uoregon.edu Subject: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-promotion-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1306/Tue Feb 28 01:50:04 2006 on mailapps X-Virus-Status: Clean Sender: owner-newtrk@lists.uoregon.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 These are personal comments only. At the top level, I believe this is the wrong solution to the right problem. I already proposed what I believe is the right solution in draft-carpenter-newtrk-twostep. I'm sure your local time machine will find this expired draft easily, but its main point was to combine DS and Standard into a single grade called Interoperable Standard, thereby avoiding makework. Now some direct comments on the current draft. > 3. Definition of the Alternate Approval Path > > Any member (or group of members) of the IETF community (identified as > "the proposer" below) may propose that a protocol specification be > reclassified as an Internet Standard if the following minimum > criteria are met. > > 1. The RFC documenting the specification, or the last-published RFC > if there are more than one, was published at least three years > earlier. This doesn't make it clear what classes of RFC are to be considered. I assume the main target is older PS and DS documents? But the text is wider. Surely some definitely need to be excluded - Historic, any Informational with a proprietary name in its title, anything Obsoleted, and anything Updated unless the update also qualifies. ... > Once an enabling document is generated, it will be submitted to the > IAD. The IESG will initiate a review process as described below. Not the IAD. The IAD has no function in the standards process. Maybe this means the IESG Secretary? > 3.2.1. Last Call Procedure > > As mentioned above, there is no pre-Last Call AD or IESG review of > enabling documents. When an enabling document is ready, and has been > posted as an I-D, the proposer may request that an IETF Last Call be > initiated by request to the IESG Secretary or other individual > designated by the IESG and announced to the community. The person > receiving the enabling document will cause the completeness of the > enabling document to be checked and will verify that the three-year > requirement has been met, then the Secretariat will issue the IETF > Last Call. This pre-last call check is a "faculty" job and not clerical. I don't see how it can be done other than by an AD or by the equivalent of a PROTO shepherd. > 4.1. IESG Workload > > To the extent to which this experiment encourages efforts to advance > documents that otherwise would continue to rest in the purgatory of > resting indefinitely in Proposed (or even Draft) Standard while RFC > 2026 insists that they be re-identified as historic and abandoned, Her's my problem. Why invent a whole new process instead of simply fixing that problem at source by fixing 2026? > 6.2. Informative References > > [decruft] Lear, E. and H. Alvestrand, "Getting rid of the cruft: > Report from an experiment in identifying and reclassifying > obsolete standards documents", > draft-ietf-newtrk-decruft-experiment-03 (work in > progress), January 2006. > > This document has been approved as a BCP and is awaiting > publication. Nit: it's Informational. (The IESG logged a decision to declassify the obsolete documents.) Brian . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html